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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-08-23 13:29:02

David Abrahams wrote:
> on Thu Aug 23 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
> 
>> David Abrahams wrote:
>>> on Thu Aug 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>>>
>>>> Wouldn't generally accepted SVN setup be:
>>>>
>>>> svd/boost
>>>>      /trunk (same as current trunk)
>>>>      /tags
>>>>          RC_1_35_1... (snapshot when tarball is created)
>>>>      /branches
>>>>           RC_1_35 (next release in being updated)
>>>>           joe_shmoes_library_development
>>>>           ....
>>> Yes, that would be usual, and it's roughly what I was going to suggest
>>> (the tag RC_1_35_1 should be something like 1_35_1a1, because we may
>>> end up releasing multiple release candidates for a given Boost
>>> version).  Is there a good reason not to follow it?
>> This is why I asked for a rationale ;-) The two reasons Beman gave (one 
>> of which I guessed):
>>
>> * To make the permissions easier to manage. (my words)
>> * Focal point for casual browsers to find release related trees. 
>> (Beman's words)
> 
>   svn/boost/
> 
>      trunk/
> 
>      tags/
>          ...
>          release/
>             1_34_1
>             1_35_0
>             ...
>      branches/
>          release/
>             1_35_0
>             ...
>          libraries/
>             python/
>             serialization/

That would work, and avoid having two directories named trunk. OTOH it 
now has two directories named 1_35_0.

Is there any point having two copies of the final for a release? 
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/

--Beman