Mailing List Archive: Catalyst: Users

Release early, release often?

Index | Next | Previous | View Threaded

sriatoook.de

Apr 8, 2005, 1:50 AM

Post #1 of 7 (1171 views)
Permalink

Release early, release often?

Ever now and then, the same old discussion comes up on irc.

Should we release early and often or only when it's "rock solid".
Both have pros'n cons.

The first opens development to the community, resulting in more patches
and influence for users,
second seems to boost confidence in the project.

This is not just a Cat question but more a general one.

What do you guys think?

--
sebastian

alan.humphreyatcomcast.net

Apr 8, 2005, 2:20 AM

Post #2 of 7 (1125 views)
Permalink

Release early, release often? [In reply to]

Put me in the "early and often" column. *As long as*:

- there's an extensive automated test suite
- all the tests are passing
- there are no half implemented features (or, if there are, they
are clearly identified)

- Alan
-----Original Message-----
From: catalyst-bounces [at] lists
[mailto:catalyst-bounces [at] lists] On Behalf Of Sebastian
Riedel
Sent: Thursday, April 07, 2005 3:51 PM
To: catalyst [at] lists
Subject: [Catalyst] Release early, release often?

Ever now and then, the same old discussion comes up on irc.

Should we release early and often or only when it's "rock solid".
Both have pros'n cons.

The first opens development to the community, resulting in more patches
and influence for users,
second seems to boost confidence in the project.

This is not just a Cat question but more a general one.

What do you guys think?

--
sebastian

_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst

torsten.seemannatinfotech.monash.edu.au

Apr 8, 2005, 2:30 AM

Post #3 of 7 (1129 views)
Permalink

Release early, release often? [In reply to]

On Thu, 2005-04-07 at 17:20 -0700, Alan Humphrey wrote:
> Put me in the "early and often" column. *As long as*:
>
> - there's an extensive automated test suite
> - all the tests are passing
> - there are no half implemented features (or, if there are, they
> are clearly identified)

I agree, but I also add:

- the included documentation matches the source code

--
Torsten Seemann <torsten.seemann [at] infotech>
Victorian Bioinformatics Consortium

eekimatblueoxen.org

Apr 8, 2005, 2:41 AM

Post #4 of 7 (1117 views)
Permalink

Release early, release often? [In reply to]

On Fri, Apr 08, 2005 at 01:51:27AM +0200, Sebastian Riedel wrote:

> Should we release early and often or only when it's "rock solid".
> Both have pros'n cons.

Why not do stable and devel branches? Release early and often with
devel (with all unit tests and no half-implemented features, as
someone else suggested), and keep the stable stable.

-Eugene

--
======================================================================
Eugene Eric Kim ......................... http://public.xdi.org/=eekim
Blue Oxen Associates ........................ http://www.blueoxen.org/
======================================================================

sriatoook.de

Apr 8, 2005, 3:10 AM

Post #5 of 7 (1129 views)
Permalink

Release early, release often? [In reply to]

Am 08.04.2005 um 02:32 schrieb Eugene Eric Kim:

> On Fri, Apr 08, 2005 at 01:51:27AM +0200, Sebastian Riedel wrote:
>
>> Should we release early and often or only when it's "rock solid".
>> Both have pros'n cons.
>
> Why not do stable and devel branches? Release early and often with
> devel (with all unit tests and no half-implemented features, as
> someone else suggested), and keep the stable stable.

Yes, i see it alike, but how would you differ between stable and
unstable? Isn't it stable (enough) when it passes all tests? :)

--
sebastian

eekimatblueoxen.org

Apr 8, 2005, 3:29 AM

Post #6 of 7 (1123 views)
Permalink

Release early, release often? [In reply to]

On Fri, Apr 08, 2005 at 03:10:47AM +0200, Sebastian Riedel wrote:

> Am 08.04.2005 um 02:32 schrieb Eugene Eric Kim:
>
> >Why not do stable and devel branches? Release early and often with
> >devel (with all unit tests and no half-implemented features, as
> >someone else suggested), and keep the stable stable.
>
> Yes, i see it alike, but how would you differ between stable and
> unstable? Isn't it stable (enough) when it passes all tests? :)

A stable branch implies better test coverage and -- more importantly
-- stability of the APIs.

-Eugene

--
======================================================================
Eugene Eric Kim ......................... http://public.xdi.org/=eekim
Blue Oxen Associates ........................ http://www.blueoxen.org/
======================================================================

alexattaskforce-1.com

Apr 8, 2005, 8:52 AM

Post #7 of 7 (1121 views)
Permalink

Release early, release often? [In reply to]

Hi,

On Thursday 07 April 2005 18:10, Sebastian Riedel wrote:
> Yes, i see it alike, but how would you differ between stable and
> unstable? Isn't it stable (enough) when it passes all tests? :)

The way I see it is as follows. A "stable" branch is always more
mature then "unstable" or "current" ( i.e. working sources ).
The "current" branch is basically work in progress and code that
may or may not end up being present in the next major release.
The code then transitions from "current" over into "stable" branch
from which a release can be made.

Having these two parallel tracks provides several benefits:

1.) You have clear separation between cutting edge ( i.e. experimental )
and production ready source.
2.) Users can choose to track either "current" or "stable". For those
that wish to use well tested production code they can choose among
one of the releases made out of "stable" branch.
3.) Established code release process

Thanks.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads