New release cycle; was: Re: [dev] Fwd: HEAD

[Jan Schneider]

Quoting Eric Rostetter <eric.rostetter at physics.utexas.edu>:

> Quoting Jan Schneider <jan at horde.org>:
> 
> > This "short time" won't happen and "release early, release often" won't
> work
> > in this project.
> 
> Won't work?  Can't work?  We should try to make it work?  Any reasons
> behind
> your statement to back it up?  Should we base the future on the past, or
> present, or try to improve on the past/present?

This statement was based on experiences from the past. We intended to
release new version much more often than we actually did when we started the
last major release cycle.
The problem is IMO that people stop maintaining the stable branches once new
releases are out. We've seen this before the releases of the current stable
branch, one of us had to merge months of work/code to the branches because
noone did between the releases. Beside that this is hard and sometimes
annoying work, it potentially introduces bugs to the stable branch because
we add a lot of new code in very few time. We've seen that it lead to x.x.1
releases in the recent versions.
 
> > I still remember well the long and winding road we had before the last
> major
> > releases. It took a lot of time and manpower to get them on the shelves
> and
> > iirc the release process took a few months.
> 
> That doesn't mean we can't change things in the future.

Sure, any ideas how to manage this?
 
> > Don't get me wrong, I'd love to see a new release cycle but I fear that
> we
> > don't have the ressources and discipline for this at this moment.
> 
> But could we develope the discipline, and help find or remove the need
> for some of the resources?

I guess we can to get new releases out but we all have to agree that this is
our goal for next two or some such months. And it doesn't mean that this
will last for the time after the releases.
 
> > > Right now, I don't see it as ready...  In a short while, maybe it
> will
> > > be.  What we need perhaps is for someone to jump up and down and
> scream
> > > and shout when we hit those points where it is ready, so we can get a
> > > release out at that time instead of making major changes which
> preclude
> > > a new release coming out any time soon.
> >
> > The only way this might work with our current ressource at all would a
> > complete feature freeze and concentration on bug fixes and stabalizing
> the
> > new stuff for the next two or three months. Do we want to do this?
> 
> I'm not convinced of your arguments.  But that aside, I'll propose
> another
> way to do it -- make a new branch.  Have the releng branches, the HEAD
> branch, and another temporary branch that is, for lack of a better name,
> the
> feature-frozen-debugging-soon-to-be-released branch...  When it is
> released, it is moved/renamed to the new releng_* branch.  That way we
> can
> still have the current stable branch, the current development branch, and
> the
> soon-to-be-released branch, and they won't interfer with each other.  In
> a sense, this would be a "beta" branch.

We switched to the current release branches system exactly to handle such
situations. This means that we'll start new RELENG_* branches on all modules
that are to be released in this cycle. This in turn means we'll have three
branches to maintain for all modules that currently have stable branches
already.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft