On 5/15/2015 2:09 PM, John Maddock wrote:

Now that the release is out it's decision time:

I'd like to merge the "Version2" branch of type_traits to develop, it passes all the tests, and I've been using it exclusively for testing and development locally for a few months now without issues. But.... it's a big change with the potential to break a lot of folks stuff if things go wrong given that this is such a core component. To recap the main advantages are:

* Removed all the redundant cruft that's no longer required for old/broken compilers we don't support anymore anyway. * Very nearly dependency free (other than Config), there's just comon_type which still has dependencies elsewhere - and even that disappears for a C++11 compiler. * Much cleaner, easier to understand code, now that the horrid obfuscating macros introduced by MPL have gone. * Fewer template instantiations than before as much of the indirection / forwarding templates have been removed. * As a result code using these headers should be somewhat faster to compile - both with fewer template instantiations, and a much lighter #include load.

Note that as a result of this change, a number of undocumented headers which were none the less being used in Boost have been deprecated. The headers still exist, but warn loud and clear about their deprecated status, so folks will get a lot of warnings to begin with. I know Edward Diener has submitted some PR's to fix these, but I plan to make a concerted attack on any remaining once the new version is in develop.

A number of those PRs are still sitting there because no one is looking to apply them. These include changes for lambda, function_types, and iterator. I applied for administrator rights for lambda and function_types, willing to deal with any bug reports and PRs in those libraries since neither is being actively maintained, but no one seems to be dealing with those requests in boost.admin. Noel Belcourt has replied to me that he has been busy but will try to look at iterator.

So here's the question, how do we proceed?

My thoughts are to basically go ahead and merge, but not merge to master until after the next release at the earliest to give everything a chance to bed down, and the required changes in other libraries to filter through. Or we could have some sort of mini-review either formally or informally to check things out before the merge - of course folks are most welcome to do this anyway!

Let me know what you think, best, John.

My vote is to go ahead, but I also feel it is important to get PRs which eliminate your deprecated warnings message applied so that testing output will be smoother. I have detailed the ones I have found above and endeavored to fix with PRs.

Now that the release is out it's decision time:

I'd like to merge the "Version2" branch of type_traits to develop, it passes all the tests, and I've been using it exclusively for testing and development locally for a few months now without issues. But.... it's a big change with the potential to break a lot of folks stuff if things go wrong given that this is such a core component. To recap the main advantages are:

So here's the question, how do we proceed? I don't know if you have run all the regression test at least on one

Le 15/05/15 20:09, John Maddock a écrit : platform/compiler. If not, this should give you a good idea of the impact.

My thoughts are to basically go ahead and merge, but not merge to master until after the next release at the earliest to give everything a chance to bed down, and the required changes in other libraries to filter through.

Do you mean that you will not merge to master for release 1.59? If this is the case, I would be against. How would you manage to fix current issues on master branch?

Or we could have some sort of mini-review either formally or informally to check things out before the merge - of course folks are most welcome to do this anyway!

Let me know what you think, best, John.

I don't think we need the mini-review. Vicente