Subject: Re: [boost] Release numbering
From: Peter A. Bigot (pab_at_[hidden])
Date: 2013-12-16 09:26:19
On 12/15/2013 07:18 PM, Jens Weller wrote:
> Yes, boost 2.0 seems like the right idea. For long term, for now theres still 1.56 - 1.99 available in the meanwhile...
> So, while we are at an important milestone, I'd like to see some ideas and goals named for 2.0 before moving to it.
> wxWidgets just got to the 3.0, and well, I kinda miss the difference between 2.9 and 3.0, they don't even got C++11 really on board.
>
> So, boost is in my opinion on a good way to get to its 2.0 release, but IMHO it should be more then just being on git.
> Also, earlier this year, there was the idea stated on this mailinglist, that 2.0 could be about a C++11/14 boost version, embracing the new and upcoming standards.
> But I'm not sure about that idea, as I think that boost shouldn't maintain two different branhces (one for the future, one for the past).
>
> Also, look at Qt, they released a year ago Qt5, but still maintain the 4.x branch, what happens to boost 1.xx after 2.0?
> Bugfixes should be maintained for both branches if you're doing it right imho.
>
> Well, not that easy I guess, but just my 2 cents...
>
> kind regards,
>
> Jens
>
> P.S. why not use C++Now (aka boostcon) next year to get the goal for 2.0?
I'm mostly lurking until I can contribute value, but this is a bikeshed
topic. IMO:
A change to the major version number of a software system should
indicate a significant increase in value to the user. Though it impacts
developers, a management decision to use a new SCM tool should be all
but invisible to Boost's users, and does not warrant an exceptional
version number change.
As Boost has always been at version 1.x, a move to 2.x also enables
interface changes to fix anything that people now feel was a mistake,
eliminate maintenance of little-used compilers, and take global
advantage of the last decade's improvements in C++. Keeping 1.x active
as a maintenance branch supports the existing users/toolchains while
simplifying future development. E.g., I develop exclusively under
C++11/C++1y, and do not want to have to worry about people trying to use
my code on earlier systems that lack new language features.
Using a face-to-face discussion to determine what major version number
changes should mean to the Boost community makes sense to me.
Also: From my experience I'd recommend doing at least release under the
new infrastructure to flush out any issues before they show up in a
release that people will assume has higher value than they would expect
from one numbered 1.56.
Peter