From: David Abrahams (dave_at_[hidden])
Date: 2005-12-06 15:05:54
Oliver Kullmann <O.Kullmann_at_[hidden]> writes:
> On Tue, Dec 06, 2005 at 01:13:52PM -0500, Stefan Seefeld wrote:
>> Thomas Witt wrote:
>> > David Abrahams wrote:
>> >>I'm all for dropping the leading 1.
>> > Yes it is meaningless, but is it worth the effort? Personally I don't
>> > think so, we have bigger fish to fry.
>> I have to admit that I don't have any idea of the effort. I would guess
>> it is a single configuration item in some Jamfile or somesuch.
> but it's not just the effort at the Boost side --- it's a worldwide effort.
> For example at my side: Since the library I'm developing uses Boost, I have
> integrated building Boost into my build system, so that also inclusion
> of header files and linking is done automatically, and this
> for different versions of boost (compiled with different compiler versions).
> I guess systems like that exist at several places.
> Now my system obviously relies in some form on the naming conventions.
> Sure, it shouldn't be too difficult to change this (but it's also not completely
> trivial in case I want to support also older version of Boost), but there is always the
> chance that you oversee something, especially regarding build systems and the
> like where it is really hard to have a reliable automatic test system for this
> purpose (so yet I don't have one). And then, once I release my library, the users
> might found out about the bug.
> Isn't there a saying in the direction of if something runs and there is no real
> reason to change, then better continue as it is? (Can't remember it's exact wording.)
> (And in this case there seems to be no reason at all to drop the leading 1.)
It seems to me that 34.0.0 ought to be just as compatible with your
system for the next Boost version as 1.34.0 is... no?
> Furthermore the naming system like 1.33.2 seems to be universally
So we should add a trailing zero, in case we ever decide to maintain
some kind of compatibility with a patch release.
> And why not having Boost 2.0 at some time? For example with C++ 0x.
I don't think Boost's major version number should change when, and
only when, there's a new version C++.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk