Re: [boost] Boost Development Environment proposal

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