Nicola Musatti wrote:
One thing I do feel strongly about: no matter how broken a library is with a specific compiler, deprecation advertising should entail a warning and not an error.
Howerver #error is all that we have in place today. For instance, Spirit refuses to work with BCB by using a #error, as does uBlas. Borland config refuses to support BCB3 or earlier by using #error. Essentially I am proposing a warning to appear the version before support is dropped, and a way to acknowledge / disable that warning.
It would also make it possible to accept platform specific patches against previous releases of Boost and maybe even allow more bugfix releases, should anybody volunteer to perform the necessary tasks.
So long as the release branch remains available in CVS, that should always be possible. Arranging for it to work **and be regression tested** might be more difficult.
A concrete example: I'm using Borland's BCB6 at work and we're stuck with Boost 1.31 because we're using uBlas, which doesn't support my compiler in more recent releases. Now I happen to know that 1.32 "almost" works and that someone has the necessary patches. Accepting these to be committed against the 1.32 branch would enable all those in my situation to at least move forward one release (I happen to know that there are at least two of us - right, Russell? :-).
As a committed Borland user myself I definitely feel your pain. I also think 1.34 could be a very important release for older Boost platforms, not just because it is the last to officially test them, but because of the std::tr1 support John Maddock has put in. This may be the only tr1 implementation available to them. Even though these are among the oldest and most stable libraries in Boost, there were some fixes checked in for better MS support on old compilers in type traits just for this release! But in the general case I believe the best way to support old compilers is to point to the last supporting Boost release. Several library maintainers were looking to drop support for the listed compilers in this release, and some are actively looking to clean up thier codebase and remove workarounds. A deprecation release was the agreed compromise - so platform supporters get notice and one whole release to really bang in any bug fixes they can find. After that, with the dwindling pool of supported libraries I believe the best we can do is point back to the last tested/supported release. I admit I would like to go further and make that a #error in the Borland config with a message pointing to 1.34, and clear out the legacy support for 3 different standard libraries etc. I am anticipating library maintainers to be doing the same, which is why we should also focus on updating all the BOOST_TESTED_AT macros to test agaist the correct version - in case 'old' workarounds get removed that we are still relying on to support the latest compiler. -- AlisdairM