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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-23 14:24:48

David Abrahams wrote:
> on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
>
>> Wouldn't it be potentially less confusing for the release manager to
>> move 1_35_0 from svn/boost/branches/release to svn/boost/release at
>> the time of release? And since there would only be one release
>> work-in-progress directory at a time under branches/release, the
>> release level could be eliminated.
>>
>> So after 1.35.0 ships, the tree would look like:
>>
>>     svn/boost/
>>
>>        trunk/
>>
>>        tags/
>>            ...
>>            release/
>>               ...
>>               1_34_1
>>               1_35_0
>>        branches/
>>            1_36_0
>>            libraries/
>>               python/
>>               serialization/
>>
>
> Sounds good to me.

This sound good to me as well.  I do have a couple of observations

To me - the "release" in tags/release is redundant so it could just as well 
be

tags/
     1_34_1
     1_35_0
     ....

The branches is fine as well.  BUT it requires some explanation for users.
I've been only recently learning how to use SVN to good advantage.  I've
been practicing on my own machine with my non-boost projects.

a) Using the SVN interface with windows is veeerrrryyy slick.  But like all
slick stuff its not quite as easy as it first appears so when you want to
do something you haven't done before you can get it wrong the first time.

In my case, I made a branch of the whole RC_1_34_0 as it looked like
making a branch of just one library would result in an SVN "branch"
structure which didn't map exactly to the directory structure.  Since
SVN uses "cheap copy" this didn't have any big impact but now I
see that it would have been simpler to do it differently.  So a short
explanation of how developers should do this would be helpful.  I think
that this has been covered in the emails but a short "SVN usage
recommendations" would be helpful.  Also I think following the
common SVN pattern is a good idea if possible.

b) I'm thinking that the tagged versions should be locked to prevent
someone from accidently checking in any changes to them.  Again
I made such a blunder in the past.  I think this is easy to do with SVN

Robert Ramey