Re: [boost] [1.48.0] Schedule discussion

Subject: Re: [boost] [1.48.0] Schedule discussion
From: Lars Viklund (zao_at_[hidden])
Date: 2011-06-25 16:18:36

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_at_[hidden]