Mailing List Archive

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@lists.rawmode.org
[mailto:catalyst-bounces@lists.rawmode.org] On Behalf Of Sebastian
Riedel
Sent: Thursday, April 07, 2005 3:51 PM
To: catalyst@lists.rawmode.org
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@lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

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@infotech.monash.edu.au>
Victorian Bioinformatics Consortium

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/
======================================================================

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

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/
======================================================================

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.