>>>> (my voice) Thus hopefully they will not mind if we just ask them to use releases in 1.31.x branch. But it also means that we will need to support two branches for (at least) next two years. This might be cumbersome, but on the other hand it should simplify development in "current" branch. (David Abrahams) Yep. It'll be cumbersome, that's for sure. Would it be any better
This message is actually result of subthread in "1.31 regressions" where I started discussion about dropping support for older compilers. My idea was to split boost to two branches : "current" and "old compilers" (based on 1.31 release). New features could be developed in "current", while "old compilers" should be still supported, and some new features (and most importantly - fixes) could be backported to this branch. Here is part of discussion: than bringing in new "non-vc6" features with #ifdefs and new non-vc6 libraries without apology?
>>>> (my voice) However, I do suggest that *if there is new branch* of boost, many regression tests targeted at old (nonconforming) compilers should be pulled out from this branch. Effectively, to make new features available for old compilers, these features have to be back-ported to the "old branch".
(Pavel Vozenilek) I am afraid it woudn't work very well: - There are many small fixed and updates and these could be easily be missed. - The effort to keep multiple branches of Boost would take more than maintaining current state.
>>>> (my voice) I think nobody is going to prevent you from supporting any compiler you want :> However, I do suggest that *if there is new branch* of boost, many regression tests targeted at old (nonconforming) compilers should be pulled out from this branch.
(Peter Dimov) That's what I disagree with. I want these compilers to participate in the regression tests, so that I can see when I inadvertently introduce a regression.
>>>>
I can see there are strong points against this idea. However, I still feel there is urgent need to simplify regression tests in order to make future releases simpler. I'd also like to give choice to developers if they want to support old compilers (like MSVC6, GCC 2.95 or BCC32) or not. Here's another idea: two sets of regresion tests. Library maintained by developer willing to support old compilers will be tested against both, while other libraries will be tested against only one. Users of old compilers will have a list of libraries which have been tested against both sets (including results) - if they don't see on this list library they need, they can still use older release of boost. B.