From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-05-25 17:00:57
James Sharpe wrote:
> 2008/5/24 Jens Seidel <jensseidel_at_[hidden]>:
>> On Sat, May 24, 2008 at 07:22:06AM -0400, Beman Dawes wrote:
>>> Peter Dimov wrote:
>>>> If yes, we'll need two release branches, one for 1.36.0, one for 1.35.x.
>>> Yes. branches/release will be for 1.36.0. I haven't given any thought to
>>> what the other should be named.
>> How about the usual name: branches/stable?
> Again let me reiterate, I'd advise against trying to keep a constant
> branch name such as branches/release or branches/stable just because
> moving branches in the repository is a bad idea, just include the
> version number in the branch name!
I'm missing something. Why would we move branches in the repository?
> This kind of system works if you
> have a good merge tool, but quite frankly subversion is a rubbish tool
> for doing merges; distributed version control systems provide far
> better merge tools that enable this kind of integration to be done
> easily; again I refer people to the example of the linux kernel or git
> for how this kind of thing is done.
With Subversion 1.5 (which supposedly implements full-blown merge
tracking) up to RC5, the ballgame is about to change.
>>>> Either way: what would the procedure for the 1.36 branch be? What is its
>>>> starting point,
>> Maybe this could be renamed into branches/next_release.
> Try to avoid moving branches as I suggested earlier it makes it harder
> to migrate to other version control systems in the future and also
> plays havoc with working copies if a new branch with the previous name
> is then created again as subversion doesn't detect the move. This is
> part of the reason I consider subversion's branching model of using
> paths for branches to be broken.
>> It is fine with me if someone else manages a 1.35.1 release, although it
>> isn't clear to me who that someone would be. Dave Abrahams is
>> interested, but I doubt he has the time available.
>> I'm personally concentrating on smoothing out the regular quarterly
>> release process so that releases happen as scheduled and with more
>> quality assurance than is currently the case. That leaves me no time to
>> manage point releases.
> Do you not consider point releases as part of the release schedule? I
> think given Boost's complexity that point releases should be a given
> and in fact that point releases will help increase quality assurance
> since they are fixing the very problems that slipped through the net
> for the current release.
I don't have an opinion on that, the question seems premature until we
see how the planned change to a quarterly release schedule plays out.
> IMO the only way to get a smoother release process is to instigate
> hard feature freezes for releases. I can't help but feel from
> observing the release process that too many last minute features are
> allowed in; this is kind of a chicken and egg problem; these features
> are pushed to go into the release because of the long release times,
> but at the same time its these addition of features that slow the
> release down at the same time.
I really don't want to speculate. Once the quarterly releases have
cycled a few times, we will have a much clearer idea of where the
dragons be. Then we can figure out how to slay them.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk