Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-06-04 10:37:13


Phil Richards wrote:
> On 2007-06-04, Stefan Seefeld <seefeld_at_[hidden]> wrote:
>> Phil Richards wrote:
>>> And, if there is an intention to change the numbering scheme and
>>> release procedure, it might be the time to move to start with a new
>>> major number (2.x). It would signify a clean break from the past,
>>> and would mean that there wouldn't be some arbitrary "as of version
>>> 1.34.1 boost is following the following numbering scheme".
>> Heh, if this is an opportunity to change the numbering, let's get
>> rid of that 'major version' entirely, i.e. make the next release
>> '35'. There is nothing versions 1.x and 1.y have in common for x !=
>> y, so the '1' is completely meaningless at this point.
>
> Fine, but why skip to 35?

'35' because it's going to be the 35th major release of Boost.

As I said in my other post - which hasn't generated much interest - I think
that we're at a point where the lock-step approach is no longer feasible;
that is, we can no longer afford to avoid versioning libraries by way of
pretending that the leading 1. in front of the release number makes it a
version.

Put differently, what I'm saying is that Boost can no longer pretend to be a
library instead of a compilation.

A release should merely be a collection of library versions that have been
tested together and known to work.

In terms of SVN structure this could look like:

trunk/
  boost/
    foo/
    foo.hpp
    bar/
    bar.hpp
  libs/
    foo/
    bar/

versions/
  foo-1.0/
    boost/
    libs/
  foo-1.1/
  foo-2.0/
  bar-1.0/
  bar-2.0/

releases/
  r35/
    boost/
    libs/

but of course other arrangements are possible.

The benefit of this approach is decentralization. The maintainer of foo only
modifies trunk/boost/foo, trunk/libs/foo and creates versions/foo-* when
he's satisfied with the test results on the trunk. The release manager of
r35 only copies library versions from versions/ to releases/r35, does
whatever needs to be done to resolve test failures by nagging the
maintainers to fix bugs in foo-2.0 creating foo-2.1 (and failing that picks
1.1 instead), and ships when he's satisfied with the test results on r35.
It's clear who can commit, where, and when, and a release doesn't block
development. It's even possible for r36 to appear before r35. :-)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk