Re: [boost] [1.36.0] Release schedule set

From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-05-23 15:02:31

2008/5/23 Peter Dimov <pdimov_at_[hidden]>:

> > Well the testing of "branches/release" has never stopped.
>
> It doesn't matter, because the current state of branches/release is largely
> irrelevant (except if released as 1.35.1).

I don't think it should be a question of if released as 1.35.1, but I think
it should be a given that if bugs are present in a particular release, that
can be fixed, keeping as much of the ABI/API the same then these bugs should
be fixed. Since large changes are allowed in modules between point releases
then it is useful to have bug fix releases that fix issues with the release
since upgrading may not be an option, due to time constraints or project
budgets, if there has been a API change, so its useful to have working
versions of a release.

> What is relevant for 1.36 is the
> state of branches/release after the merges from trunk are done, and this
> isn't being tested, because it doesn't exist yet.

As to branch management I think that the best method for boost will be to
name the branches after the major release number i.e. so the next release
development will be occuring on branches/release1_36 and not just
branches/release. This makes repository management a lot easier in the long
term too (should boost move to a distributed version control system this
branching convention will be a lot easier to import).
So what I would propose is this:

branches/release gets moved to branches/release1_35 and a 1.35.1 release be
made from fixes on this - not a huge amount of work since essentially just
patching up from trac bug reports, ensuring changes are also merge on trunk
and release1_36 (where applicable).
branches/release1_36 gets made from trunk asap
Then development for 1.36 happens alongside 1.35.1. Ideally the branch for
1.36 would have been made after feature freeze for 1.35 occurred. The reason
for this is that it enables trunk to become a stabilising area for features
for the next release i.e. it implicitly becomes release1_n+1(any features
not ready for integration should be developed on a feature branch branched
from trunk to be later merged back to trunk).

Before 1.35 was released I did try to start discussion that 1.36 should be
branched before the actual release (i.e. when a feature freeze began) and
that the release team for 1.35 should then continue to manage the branch for
bug fixes and that a second release team should begun integration for 1.36.

I think a good model for boost's release procedure would be one similar to
that of the linux kernel. Having a merge window for a particular release for
new features, then a stabilization period before releasing could suit boost
well due to the nature of the project.

James