Re: release policy

[Peter O'Gorman]

Gary V. Vaughan wrote:
> Peter O'Gorman wrote:
>
> > Gary V. Vaughan wrote:
> > |>>We can always choose to stick with a troublesome stable branch for
> > |>>longer if it turns out to need more work to iron out any bugs and
> > |>>regressions rather than ploughing on with another head release...
> > |>>thoughts?
> > |>
> > |>
> > |>Yes, just one: this is INSANE.
> >
> > I like the idea (stolen from gcc) of deciding at the start what features
> > need to go into the next feature release, and not allowing others to be
> > added until after release. Features can, of course, be removed.
> >
> > By limiting the number/scope of features in each release a more frequent
> > release schedule is possible.
> >
> > Does this sound reasonable?
>
>
> Yes, certainly.  And it is not incompatible with a time based release
> system -- in fact, gnome and gentoo work this way, and make regular
> timely releases as a result.
>
> How often do you think we should be aiming to make a release?  Is my
> idea of one alpha, one feature, one stable and one maintenance release,
> per branch, per year truly barking mad?

Hi Gary, Ralf.

The thing is that I agree with Ralf here, releases should be made when 
necessary on the stable branch, and when features are complete and tested on 
HEAD.

Say, for a wild example, that we decided the next feature 2.2 release would 
be entirely rewritten in perl (chosen for the unlikelyhood), we'd have to 
wait until that was done and tested fairly well before release, and that may 
well take a couple of years. And during that time, haha, there may have been 
no bugs fixed on the previous release, because it had no bugs :), meaning no 
libtool release at all for 2 years. That's okay.

Peter