Re: [Chicken-hackers] new release policy

[felix winkelmann]

On 9/1/07, Peter Bex <address@hidden> wrote:
> On Sat, Sep 01, 2007 at 07:28:37PM +0200, felix winkelmann wrote:
> > The chicken version has been bumped to 2.701, now. There will be
> > no more "official" releases from now on, just continuously created
> > snapshots.
>
> IMHO this is not a good idea.  Other projects make official releases
> with a reason.
>
> An official release tells me that someone in charge considered the
> code at that point in time as worthy of being distributed.  It means
> it has been (hopefully) tested thoroughly, that no experimental new
> features are in there that might mess things up and it provides one
> with an easy way of tracking what issues people are having.

That distinction always felt arbitrary to me. Can you define what a
suitable version
for a release is? Version X or version X + 1 with bug Y fixed?
Chicken doesn't have any "unstable" versions. The HEAD is always
(ok, should always) the best, most stable version and experimental
versions should go into subversions branches. Software is never finished
and never "good enough" for a release as bugs get continuously fixed.

>
> Not making releases makes Chicken even more of a moving target than
> it already is.  It makes life unneccessarily difficult for packagers
> and casual users.  It will possibly mean every single user could be
> running a unique chicken version.  When someone reports a problem with
> a stable version, people will be able to tell them "oh, that's a known
> issue with version this-and-that", but if automatic snapshots are made
> you can get the situation that there will be an intermittent problem
> between two snapshots, and an unlucky person might just get the version
> with this bug.

I don't quite see it that way. Any serious use of chicken requires eggs anyway,
which are moving targets. The versions of eggs used by a particular user
already define a configuration that is hard to reproduce.
How many different gcc versions are used by the members of this mailing
list, for example? Is this is a problem, and can it be avoided?

To emphasize: there are no "stable" chicken versions and never where.
There where broken ones, sure, and there will be more of them, but not
intentionally. The universal creed of "try the newest version" still applies
to chicken as to any other piece of heavily developed software (whether
it has some elaborate release process or not).

>
> So I'm wondering: why do you want to make this change?
>

I want to optimize the development process and I want to avoid situations
where release maintainance takes up too much valuable development time.
It is more important to fix bugs right away than to define mostly arbitrary
processes that in the end don't make the software any better. Everything
that can be automated should be. People come and go, but simply commiting
fixes to the repository is something everybody can, and which lowers the
hurdle to contribute.


cheers,
felix