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

[Eric Rostetter]

Quoting Jan Schneider <jan at horde.org>:

> The problem is IMO that people stop maintaining the stable branches once new
> releases are out.

Yes.  The new discipline we need to develope in the developers is to 
make sure that when we fix a bug, or add and test a feature, and assuming
that it is bc or can be coded bc, we do merge it back into the releng_*
branches.  This avoids the long merge/test cycle we get into when we
do want to cut a release, making it an ongoing process instead.  No one
uses the "merge after" field on a commit, AFAIK.  And almost no one merges
fixes down into the releng branches.  I'm guilty of this too, even in my
own modules...

Any way we could automate something that would check for "merge after"
dates/contents in cvs and create a notice, or something like that?  Not
sure if it is possible, but it would help perhaps (assuming we used 

If we don't want to use the "merge after" field for a date, perhaps we could
at least use this for an "other module dependency" kind of thing?  Merge
the change into IMP stable once we get to Horde x.x version?

> 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.

Yes, this is the biggest problem with minor release versions (2.1 to 2.2)
but it shouldn't be a problem for new releases (2.2 to 3.0), should it?

> 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.

Agreed.  But all this means is we are not merging stuff as we go along
as we should be.  If we did it as we went along, rather than trying to
do it all at once at the last minute, we'd have fewer problems, and find
them earlier.

> > 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.

I think we need to decide this is the way we want to do it in the future, and
it has to last.  Otherwise, we've not made any change, and hence no
improvements.

> 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.

So the idea would be to create new releng_* branches, get them tested, and
then release them?  That sounds good.

> This in turn means we'll have three
> branches to maintain for all modules that currently have stable branches
> already.

Don't we have more than that for any branch with more than one previous
release?  releng_1, releng_2, releng_3, head, etc?
 
> Jan.

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!