Re: [boost] Change to Release Procedure? (was: Another remindertomerge changes from the release branch)

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-03 10:47:25

Samuel Krempp <krempp_at_[hidden]> writes:

> Le lun 28/10/2002 à 04:19, David Abrahams a écrit :
>> Also, in this version of the command line instructions I dropped
>> > all the last_merge tagging instructions.  This seems like lots of 
>> > extra complexity without much purpose.  But perhaps I'm missing 
>> > something so please review and comment.
>
> If my guess is right, the role of the tag really was to serve as a base
> for the next merge. 
> In trunk (old procedure style) :
> cvs up -j <branch>_last_merge -j <branch>   <files>
>
> Without this tag, we have to remember what was the previous version of
> merging, and batch merges are not easily applied.

However, batch merges into a release candidate branch seem as though
they should be (very) rare.

> When all changes to trunk are propagated to the branch, this version to
> remember is merely the last version when we did a merge, and could be
> stored in a tag (strictly symmetrical to the <branch>_last_merge)

In fact, we could still call it that, though more-explicit
source->target naming might be helpful.

> In order to make sure I got the procedure right, let's consider the
> example of a simple library with an issue, that the author wants to fix.
> he tries his fixes and improvements in the trunk, and when satisfied
> (regressions show OK) merges the trunk into the branch.
>
> In this situation, keeping a tag of the last merge (but on the trunk
> side. so we need a new tag name, e.g. <branch>_next_merge_base) 

Yick. But OK...

> makes everything smooth. You can even merge a whole directory in one
> line, once the regressions show you fixed the issue without causing
> new ones.

Sure, I guess. I'd prefer to manually review each change that goes
into the branch, since other development may happen in the trunk.

> I understand you were speaking of situations where some
> modifications were applied that should not go into the branch, and
> the version to remember would not necessarily be the one of the last
> merge.  (BTW what kind of changes should an author restrict himself
> from merging into the branch, if it doesn't seem to break any
> regression ?

"Major, potentially destabilizing changes". It's a judgement call,
really.

> keeping the branch synchronised can be a major relief
> for the author) 

What do you mean by "synchronized"?

> In fact, in this situation, you can 'remember the version', by
> putting this tag '<branch>_next_merge_base' right before modifying
> the file.

The person who initially creates the branch should also create the
merge tag at the same time.

> In both cases, the tag has the same use : it  is intended so as to allow
> later 
>
> cvs up -j <branch>_next_merge_base -j HEAD   <files>

Sure.

> (thus it's more a predictive 'next_merge_base' tag than a 'last_merge'
> one in my opinion)
>
> All in all, I think in most cases a <branch>_next_merge_base tag
> will simplify the merging hasles imposed on the maintainer, and it
> should be added to the procedure docs.

It might. I think it will seldom be used, but I don't mind adding it
as long as developers also understand that especially in a RC branch,
all changes must be individually reviewed, even if they're created by
using an auto-merge. A false sense of security about using -j would be
dangerous.

> (A better name can be found, that's not my point here. but at least,
> calling it <branch>_next_merge_base corresponds quite precisely to
> its use)

True. However, I would prefer a standard tag format for
branch-to-branch synchronization labels, e.g.:

   sync_<source-branch>_TO_<target-branch>

And, of course, a nice front-end script for cvs which automatically
creates these tags for us and automates the merge process ;-). Oh, and
of course, integration with Emacs <wink>.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution