Re: [boost] [1.36.0] Release schedule set

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,
>>> branches/release
>> 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.

--Beman