Re: [boost] Future release schedule (Was: 1.35 release approach)

From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-05-01 13:06:28

On 01/05/07, Jeff Garland <jeff_at_[hidden]> wrote:
>
> After the '1.34 experience' I've become even more of an advocate a hard
> line release approach. That is, we
> should set the deadline and only accept code that can make it in the
> release timeframe -- if it's not ready then we take it out and let it slide
> to the next release.
>
> To minimize risk of delay and release the pent-up backlog of new libraries
> I
> believe we should hold all existing 1.34 libs constant and only add in new
> libraries that are basically ready to go now.  I've actually done an
> 'alpha
> test' of this approach and it looks like this will work -- that is, most
> of
> the unreleased libraries can be build against a 1.34 core without
> dependencies
> on changes to existing libraries (there are a few minor
> exceptions).  Behind
> the scenes I've been encouraging developers of new libs to get their code
> into
> CVS so we will be ready to begin the nano-second after 1.34 ships.

Not wanting to detract from the 'move to subversion' discussion (which
I-for-one am glad is happening), I've been wondering about the what 'hard
line release approach' entails.

FWIW, to me this would imply a skeleton policy like so:

a) Set a monthly/2 monthly/whatever deadline for a release.
b) Straight after each release, a new branch is formed for the release
testing
c) If a developer thinks a library of theirs is 'ready' then they add it to
the testing branch. Regression tests are done on these libraries
d) As the deadline approaches and an RC branch is created, libraries that
pass tests can be added. Tests are still only done on the testing branch
(assume the RC branch code is the same as the testing branch code)
e) At the deadline the release is done, following the normal rules: minor
increment for updates, major increment for new libraries.

Obviously that is a very raw suggestion and ignores the possible complexity
of making regression test scripts work with this, about which I know
nothing.
Concerns it addresses are:
1) Library maintainers don't have to wait a long time to add fixes to their
library - something which means the boost repository stays out of date with
the developers' own since there's little point keeping two up to date.
2) New libraries could potentially be added at any point.
3) HEAD will be usually be comparable to RC
4) Release quality won't be compromised (in theory).

They're just things I've been mulling over for a few days. Thoughts?

Darren