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