On Sat, Jun 25, 2011 at 09:18:40PM +0200, Ruediger Berlich wrote:
Hi all,
Beman Dawes wrote:
In the "[boost] [1.47.0] Release branch now closed" thread, Daniel James and I discussed possible schedules for 1.48:
out of pure curiosity: why not a Boost 2.0 release ? I think that 47 releases in the 1.0 series and an additional number of "point" releases is enough to warrant an upgrade of the major version number. An extra long bug- sprint might be in order, so that the hallmark of Boost 2.0 would not be an incredible amount of new features, but incredible stability.
Bumping the major version number would turn some people off, as in most version numbering schemes, that tends to mean that some major incompatibilities were introduced or that some restructuring has occured. I've seen and caught code in Boost that will break if the major version number is bumped, as it only checked the minor version in preprocessor tests. It wouldn't be far-fetched to assume that other people have made such assumptions as well. Personally I prefer that code and scripts that have worked in the past continue to work to some degree, particularly if the change is for just "because we can" or for cosmetic reasons. This (personally) sounds to me of being inspired by the recent version number bump of the Linux kernel to 3.0.
And I believe that, with an upgrade of the version number, we would see quite a big effect in the number of users and in the press coverage of Boost.
As per the above comment, major version bumps also scare people. I would say that the effect of a major bump would be rather anticlimatic when/if people get to the changelog and see that nothing interesting has occured. If I saw a bump of Boost to 2.x.0, I would expect that something massive and somewhat breaking has occurred, along the lines of: * complete build system revamp, with different build methods and library naming convention; * modularisation of boost libraries into largely standalone components, with some infrastructure to roll monolithic and custom releases; * in essence - Ryppl and the Boost.CMake effort. I would consider it a waste of potential to bump the version number for things of little consequence when there are things in working that have real impact on the way Boost is seen and how it is used. -- Lars Viklund | zao@acc.umu.se