On Sat, Dec 14, 2013 at 8:32 AM, John Maddock wrote:

...

Will the first Git release of Boost be 2.0? If not; why?

...

+ 1

Why don't you start a separate thread so your suggestion gets the airtime it deserves?

OK.

I think the Git transition is a good time for 2.0. This would somewhat make it easy to understand what part of the history to look for in Subversion. The Git transition is major for Boost.

How about numbering releases YYYYMMDD - so for example the next might be 20140201 or whatever...

IMO the date is less useful that the traditional numbering scheme, which coveys useful information like if it is a point release, regular release, or major release, and allows you to easily see how many release separate two regular releases. --Beman

On 14.12.2013 23:35, Klaim - Joël Lamotte wrote:

I find strange a change of major version number just without a major interface change in the code, as the way the code is managed is not really related to the software state. So it feels a bit weird.

I agree that 'we've moved to git' as major feature of 2.0 sounds quite strange. And modulaization probably can't be major feature either - we've just sliced existing code in pieces. It is not necessary any better or truly modular as the result. And if there are some 'real' major features planned for 2.0, it would be really great not to mix everything together, and first release one 'normal' release at least. - Volodya

On 15/12/2013 08:42, John Maddock wrote:

...

I agree that 'we've moved to git' as major feature of 2.0 sounds quite strange. And modulaization probably can't be major feature either - we've just sliced existing code in pieces. It is not necessary any better or truly modular as the result. And if there are some 'real' major features planned for 2.0, it would be really great not to mix everything together, and first release one 'normal' release at least.

I feel it's as good a time as any - the libraries may not have changed much but the infrastructure has.

Playing Devil's Advocate for a moment: <DA> With an end-user hat on, who will only ever download the tar-ball of the latest release, how precisely does the internal infrastructure affect me, and why does it merit a change to the end-user visible version number? </DA> The only people who are really interested in the Boost version number are the people who download the tar-ball. Developers are using git and know all about the change. They don't need a version number to tell them. I still think that the most sensible reason for moving to v2 would be to indicate that C++11 support is expected. v1.x could be used for maintenance releases for pre-C++11 compilers. A library may appear identically in both the v1.x and v2.x releases, or it may have split into two release branches, at the decision of the maintainer. This would allow maintainers to move to supporting just C++11 for new work whilst leaving the pre-C++11 library available in the v1.x release series. Testing overheads wouldn't be significantly different: each compiler configuration would be either v1.x or v2.x: compilers with switchable C++ version behaviours would need multiple configurations - but they do now, anyway. v3.x would be for C++1y. (If there are sufficient differences to justify it.) Biggest hassle (and I don't underestimate the effort involved in this) is the release process. Just my thoughts as a long-term lurker, Phil

On Dec 16, 2013, at 1:24 PM, Stefan Seefeld wrote:

My main concern with the current numbering scheme is that the current 'major' number is entirely meaningless. There is absolutely no concern for compatibility between releases 1.X and 1.(X+1), so making a distinction between 'major' and 'minor' seems a little pointless.

You make an excellent point, but a future release that forgoes C++98/03 altogether, would certainly warrant a major version number bump. However, if we can't agree on such a break a priori, I suspect it won't happen. If we agree to take that direction, then using 2.x to indicate modularization, or even just the Git transition, isn't out of the question.

Thus I think that a switch to 2.0 would reinforce a notion of a metric that doesn't exist.

Maybe not, after all.

Thus, I'm still thinking that the best change in numbering would be to remove the '1.' prefix (and it really is nothing but a common prefix !), and continue to number with a 'flat' scheme N, N+1, N+2, ...

So, the next version would be 56, not 1.56. And if there is a need for a 'minor bugfix release', that could then be captured in an exceptional 56.1 number. But please, get rid of the redundant leading '1.' !

That makes a lot of sense should we choose to skip using the major version to indicate language transitions. ___ Rob (Sent from my portable computation engine)

On Dec 15, 2013, at 8:18 PM, "Jens Weller" wrote:

...

...

...

Will the first Git release of Boost be 2.0? If not; why?

+ 1

+1

...

I think the Git transition is a good time for 2.0. This would somewhat make it easy to understand what part of the history to look for in Subversion. The Git transition is major for Boost.

+1

...

Next major revision could be when a C++ version is not officially supported anymore. E.g., when no testers exist.

There are a number of such changes that could warrant major version changes.

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.

-1

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).

I can see both sides of that argument.

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.

Boost can maintain the older branch as long as there are maintainers, but there's no obligation when all, or even most, have moved on. I think Boost can be a little freer with the major version number. After all, we're still on 1 after all these years. ___ Rob (Sent from my portable computation engine)

On Sun, Dec 15, 2013 at 6: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.

Does that mean we have separate long-term branch(es) (master/develop pair) for boost 1.xx in addition to the develop and master we have now? What would they be named? Michael

On 16 Dec 2013 at 8:26, Peter A. Bigot wrote:

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.

Thing is, one of the most often requested "features" for Boost is modularisation. I personally think a 2.0 release should be seriously breaking, with lots of libraries explicitly *removed* from a 2.0 release, but I can see the point of those thinking that mere modularisation is enough for a 2.0. I like a v1.9 release though. It implies "last iteration of the C++98 compatible Boost". Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/