Re: [boost] Which CVS release procedure?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-21 19:24:57

Agreed. We can always tag an individual branch revision for release if
development happens to have proceeded past the point where a bug fix needs
to be made.

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Thursday, December 20, 2001 11:38 AM
Subject: Re: [boost] Which CVS release procedure?

> At 08:57 AM 12/19/2001, David Abrahams wrote:
>  >
>  >----- Original Message -----
>  >From: "Beman Dawes" <bdawes_at_[hidden]>
>  >To: <boost_at_[hidden]>
>  >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.
>
> Is there some way to do a release branch that never gets merged back into
> the main trunk?  Then how do the fixes get applied to the main trunk?
>
> --Beman
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>