Re: Which CVS release procedure?

From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-20 11:50:13

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 08:57 AM 12/19/2001, David Abrahams wrote:
>  >
>  >----- Original Message -----
>  >From: "Beman Dawes" <bdawes_at_a...>
>  >To: <boost_at_y...>
>  >Sent: Wednesday, December 19, 2001 8:42 AM
>  >Subject: [boost] Which CVS release procedure?
>  >
>  >
>  >> It has been suggested by several people that we do some form of 
a
>  >> pre-release code freeze well-prior to the actual release.  This 
will 
> give
>  >> us time to resolve regression test failures before the actual 
release.
>  >>
>  >> Two different CVS procedures were suggested for implementing 
the 
> freeze:
>  >>
>  >> (1)  At the freeze date, create a branch for the release.  
Apply fixes 
> to
>  >> that branch until satisfied.  After the release, merge the 
branch back
>  >into
>  >> the main trunk.
>  >>
>  >> (2)  At the freeze date, tag for release.  Apply fixes to the 
main 
> trunk
>  >> (updating the tag) until satisfied.  No post-release merge is 
required.
>  >
>  >With procedure 2 it seems to me that there's no point tagging 
until the
>  >actual release goes out. You still need to rely on people to keep 
major
>  >changes off the main trunk.
> 
> No (unless I'm missing something), that isn't a problem.  What gets 
> released isn't the current main trunk, but the tagged set of 
files.  Thus a 
> developer can continue to modify the main trunk - if the 
modification 
> should go in the release, the file must be re-tagged - if the 
modification 
> is not to go in the release, the developer doesn't have to do 
anything at 
> all.
> 
> I really see any procedure involving a branch as a major hassle 
because of 
> the later merge.  Who is going to do the merge and resolve the 
> conflicts?  It can't be a central administrator because that person 
won't 
> have the knowledge to resolve conflicts.  So it would have to be 
individual 
> developers.  And that's just not feasible with so many developers.

Who ever makes a change to the branch is responsible for merging to 
the trunk.  And he need not wait until the end to do so.  So if you 
correct a bug on the "release branch" and check it in you simply 
immediately merge this onto the trunk.  Someone else can come along 
afterwards and fix another bug and merge back onto the trunk as 
well.  So I don't see how this can be considered too complicated 
because of the number of developers.  The number of developers is 
really irrelevant to my mind.  The only complication is the extra 
steps required to check in bug fixes, which will require 
some "training" (aka documentation) and discipline, but that's true 
of any development effort with multiple developers.

Bill Kempf