Re: [boost] Updated Development and Release Practices for 1.35.0

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-09-04 17:00:04

Vladimir Prus wrote:
> Beman Dawes wrote:
> 
>> The Development and Release Practices trac wiki page has been updated.
>> See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
>>
>> The most important changes were refinements of the repository
>> organization and addition of more specific procedures for merging from
>> the trunk to the next release. The merging is described in terms of
>> TortoiseSVN. It would be helpful if someone familiar with command line
>> svn provided an equivalent set of instructions for command line users.
>>
>> I'm trying to restrict the process to things we can do right away, so we
>> can get started on 1.35.0.
> 
> I don't think I see the answers to the below question that I've previous posted:
> 
> 1. The procedure for merging to release-ready tree needs
> more details -- if the procedure is painful, then authors just
> won't merge anything.

Yes, the easier the procedure is, the better.

We are strongly urging developers to become familiar with synmerge.py, 
and use it to simplify branch management See 
http://www.orcaware.com/svn/wiki/Svnmerge.py.

Incidentally, Subversion 1.5 will build in the functionality of svnmerge.py.

> Say a great new feature is developed on trunk, but
> causes regression on a obscure platform. Author failed
> to fix that regression after reasonable effect, and platform
> experts failed as well. Can this change go to release tree still?

Sure, as long as it is marked up as an expected failure. There are no 
plans to change the markup procedures for failing tests AFAIK.

> 2. Say Boost 1.35 is released. Week later, a big source-incompatible
> change to some library is merged to release-ready tree. Week later, a serious
> bug is found in another library. Is there a place where that bug can be
> fixed? Release-ready tree already has source-incompatible change to other
> library? In other words -- from which tree is 1.35.1 going to be released?

Up to the release manager, perhaps after discussion on the. Between the 
way we tag releases and the facilities of Subversion, the release 
manager will be able to start from wherever is best. My guess is the the 
starting point is always the prior release, so the just merged change 
gets moved aside until the next 1.36.0 release.

> 3. Even assuming release-ready tree haven't got any big changes -- 
> what is the planned procedure for fixing issues discovered on release-ready
> tree? Trunk might be in the middle on the next big change, so a fix can either
> (1) be made on brunch and then merged, or (2) be made on release-ready tree
> directly. (1) requires on-demand testing of branches. Is (2) the way to go?

Release manager decides. (1) is preferred because it minimizes change of 
release branch becoming unstable, but (2) may be acceptable to the 
release manager if working copy testing has been extensive enough.

> Concerning (1), your definition of release ready will prevent merge if there
> even a single regression.

I'll change the wording to make it clear markups are still allowed.

> And (2)-(3) are not addressed at all, as far as I see.

We don't have to have procedures in place for every possible 
contingency. Let's get started on a release; we can refine procedures as 
experience dictates.

Thanks,

--Beman