|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-12-20 11:38:50
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk