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