Phil Richards wrote:
On 2007-06-04, Stefan Seefeld <seefeld@sympatico.ca> 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. :-)