Re: [boost] [1.36.0] Release schedule set

From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-05-24 10:33:52

2008/5/24 Peter Dimov <pdimov_at_[hidden]>:
> OK. To explain why the question is important, and why the proper time to ask
> it is now:
>
> Developers need to know how to deal with bug reports against x.0. The usual
> procedure is to issue x.1 with the bugs fixed. For this to happen, the bug
> fixes need to be committed somewhere. Currently this somewhere is the
> release branch due to lack of alternatives.
>
> If we're leaving the x.1 door open, we need to address this question, and we
> need to address it before parts of trunk get merged into the current release
> branch. One easy way is to copy release to release_1_35 so that the 1.35.0
> bug fixes have a place to go. The obvious problem is that no tests would be
> running against that branch.

Indeed, this is the best solution as it provides a branch for
maintenance of a given release. Although current practice is not to
provide any kind of longer term support for a release, I can't see
why, should a volunteer step forward to maintain a given release for
longer periods why a branch shouldn't continue to exist for a given
release, by not naming the branches with the release number I think
you will be shooting yourself in the foot for the longer term.  Sure
you could create a branch from the tag but that just feels messy to me
IMO (and again not ideal for importing into DCVS systems btw. if
anyone wants a complete boost history in git I can make that
available).

> Another alternative is to release 1.35.1 first from the current release
> branch, then start 1.36. The obvious problem is the possibility of 1.35.2.
>
> A third alternative is to declare that we're no longer going to issue point
> releases. This implies that the proper place to fix bugs against x.0 (before
> the x+1.0 merges happen) is on trunk.

I'd strongly argue against this alternative for two reasons:
1. A new version implicitly brings with it new libraries, potentially
new APIs and deprecations. For a company relying on boost in their
project an upgrade every 3 months that isn't just bug fixing can
potentially become a major job and more critically one that doesn't
get done due to time/budget constraints.
2. We're not always going to get a release right; should we mess up
then why shouldn't a quick point release be viable; in fact why should
point releases take much time at all?
I'd suggest that after a release testing on a released branch should
become on commits only and that commits should only be in response to
trac tickets against the release, no other commits should be allowed.
I think that this would ease the process of making point releases and
wouldn't be a huge workload IMO, also I don't think we should be
afraid of making quick point releases (Since this is essentially what
happens once we get to beta/RC stage anyway), even if they only fix 1
or bugs, it all helps to increase the quality of boost that the end
user sees.

James