Re: [boost] [1.36.0] Release schedule set

From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-05-24 08:41:01

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! 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.

>
> > > 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.

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.

James