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