which might sidestep some of the recent iterator_range anarchy, and simplify other major transitions. N.B. I haven't really thought about the ramifications of doing this, so the idea might be completely unworkable in practice.
It also allows multiple versions of boost to exist in the same executable without ODR violations. The ability to configure boost that way would be most welcome.
While the above seems like it may be useful, I can also see some potential difficulties. We would probably need to try and come up with a set of guidelines for users and developers on how to best take advantage of such a system. Here are a few things that come to mind:
1) From the discussion here, it is clear that a lot of users are very flexible when it comes to upgrading to a new version of boost. As such, they would want to just keep writing boost::foo, so that when they upgrade, their code continues working without having to go through and change boost_X::foo to boost_Y::foo.
I think that the only change that would need to be made in most end- user code is a namespace alias: using namespace boost = boost_1_38_0; The advantage of this is that upgrading to a newer boost library will trigger a compile-time error. You also have self-documentation on the version of boost that was used to develop the code.
below make me think that having versioned namespaces is not an alternative to the new/stable release cycle (I don't think the original poster necessarily intended it to be).
Right, it was not my intent to say anything about the idea of flagging libraries new/stable (which I also agree seems like a good idea).
I also have to say I can't quite see how it would have solved my original problem with Boost.Range.
My understanding of your issue may be incomplete, but I imagined that you would just include the boost_1_32_0 headers in files relying on the old iterator_range behavior. This would allow you to continue to use that version of the code, while simultaneously using more recent versions of other boost libraries (as Dave pointed out). In fact, I was even thinking that previous releases of the libraries could be retrospectively altered with the new boost namespace policy and re-released to provide some backward continuity.
2) While having different boost versions in different namespaces will allow different versions to exist in the same executable, because they are not interchangable, there cannot be any interoperability.
That may be true, but it may be the case that you inherit some code that uses an older version of boost, and you would like to modify or extend part of that code with newer boost library facilities without having to mess with the older, tested code that already exists. By having unique namespaces, you can accomplish this relatively easily. The main issue I see is naming of header files : should the directory structure also be altered so that the headers are, e.g., #include <boost_1_38_0/units/quantity.hpp>? This seems safest, but imposes some additional overhead.
a) The different parts of the executable (e.g. your code and the vendor library) use a disjoint subset of boost. Possible, but seems unlikely.
I actually think that this is fairly probable, since larger projects/ vendor supplied libraries generally are (for good reasons) slow adopters, if you want to use one of the shiny new boost libraries without breaking the vendor code, having the namespace separation would be nice.
I think the plug-in case may be important enough to make this change. I've had some other middle-of-the road ideas but I think we are already talking about introducing a big burden on the developers here.
The real issue is how can this be done in a way that minimizes the impact on both developers and end-users. It seems like some clever preprocessing could help ease the transition... Matthias