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

From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-12-03 12:53:09

le Mardi 3 Décembre 2002 16:47, dave_at_[hidden] écrivit :

>> 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 get that point..

In not-so-active libraries such as mine, there are not a lot of 
developpement in the trunk, so a 
cvs diff -j <branch>_next_merge_base -j HEAD | less 
is enough to check the changes before batch-merging them with
cvs up -j <branch>_next_merge_base -j HEAD

the use of the tag depends on what kind of developpment takes place.
I know this is practical for me, but I'm not pretending I know how it is for 
most maintainers
 
>> keeping the branch synchronised can be a major relief
>> for the author)
> 
> What do you mean by "synchronized"?

I meant synchronized with the release branch.
In fact, I meant this :
for a simple library, the release procedure introduces the need to care 
about two branches (trunk and RC_xxx ).
but it might be that all work in the trunk is intended to be merged to the 
branch. 
this is a specific situation, where the branch is only used to keep 
regression-error-free snapshots of the trunk.
('synchronised' was not quite the word)

for such cases, the tag makes things real simple. (just care about the 
trunk, and batch-merge to release when it's ok)

so, depending on how rare this situation is, the tag can be useful, or not 
so..

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

right.

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

I understand that. 
I think the procedure docs are most helpful to the small libs maintainers, 
for whom branches versions have good chances of being mere snapshots from 
the trunk, 
and for whom cvs procedures can be a headache.
that's why I proposed to mention such a tag in the docs.
But if only few maintainers may find it useful, it's best to leave it up to 
those that are interested, I have no will to impose the tag. I can use it 
on my own just as well.

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

okay, that's what I assumed.
for 'leaf' libraries (those that other libs don't depend on) those changes 
are quite exceptional,
while for central libraries any change should be looked at carefully.

-- 
Samuel