Re: [boost] A branching/tagging idea for releases

From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-06-29 20:18:40

What we gain is the ability to be making bug fix releases of previous
versions whilst working on the next release. With the current system
there is no way of doing this simultaneously, if we want a bug fix
release, which I'd suggest should happen, given the demand we've seen
on the list, we need a method of doing so.

As far as testing, the issue of manually updating the builders could
be dealt with by having a config file available on boost.org which
specifies the svn path and configuration that should be tested.
Updating the release testing group is then simply a matter of updating
this one file centrally. Deficiencies in the testing scripts should
not be a reason to disregard a particular release procedure if the
deficiency can be addressed IMO.

Also with regard to stabilising trunk,  I agree it won't be as easy,
so instead maintain the current pratice and simply change the proposal
to branch from the last stable release, thus giving the option of
continuing to maintain the release on the same branch.

As for tracking release history, try out some distributed version
control systems, such as git or bzr, they make this kind of thing much
easier, and I think that we should seriously be considering using
them, this would mean we could get rid of the sandbox, since new
libraries an simply be considered as branches from trunk, whih could
have an enforced naming convention so it is clear they have yet to be
accepted.

James

Sent from Google Mail for mobile

On 6/29/08, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> Daryle Walker wrote:
>> Here's an idea on how we can manage our source-control for releases:
>>
>> 1.  When we're ready to start a new release, make a branch from the
>> trunk with a name like release_1_??_x (e.g. "release_1_37_x")
>
> Why? What do we gain from having the release branch tagged with the
> version? Why branch from trunk? And there are various drawbacks, some of
> which where raised the last time we discussed this:
>
> * It means testing process needs to change to switch to a new branch at
> the start of each release. This is currently a *manual* activity which
> needs coordination from many people.
>
> * It makes it harder to track changes across releases since we have to
> backtrack through copies of loosely related source trees.
>
> * It makes it harder to stabilize the code for release since the trunk
> will have many more unstable changes. This is the *key* reason we
> switched from basing releases on trunk. And without this change a
> release every 3 months is impossible.
>
>> 2.  Finalize what needs to be done to make that branch ship-worthy
>> 3.  Make a tag from that branch with a name like release_1_??_0 (e.g.
>> "release_1_37_0")
>> 4.  Export that tag to a fresh directory and create the appropriate
>> archive file to upload to SourceForge, etc.  (The directory shouldn't
>> have any source-control debris in it.  Maybe this needs to be done once
>> on each platform to ensure the best archive format and the proper
>> line-ending markers.)
>
> We already do that.
>
>> 5.  If bug-fixes for that release need to be done, continue to use the
>> release_1_??_x branch (and merge the fixes back to the trunk, or vice
>> versa)
>
> If a bug fix release is needed a branch can be created from the
> release_x_yy_z tag at any time. And it can follow the usual merge of
> patches and release procedures. Once that patch release is tagged and
> released the corresponding branch can be deleted, and the next patch for
> that release can start again from the appropriate tag.
>
>
>
> --
> -- Grafik - Don't Assume Anything
> -- Redshift Software, Inc. - http://redshift-software.com
> -- rrivera/acm.org (msn) - grafik/redshift-software.com
> -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Sent from Google Mail for mobile | mobile.google.com