AlisdairM wrote:
It has been agreed that several platforms will be deprecated in this version of Boost. To support that I have added a warning to the Borland config to alert anyone using old versions of this platform that it is being deprecated and this is the last compatible release.
What I notice is the warning gets annoying pretty quickly.
I propose to wrap the warning in the following test:
#if __BORLANDC__ <= 0x581 && !defined(BOOST_ACKNOWLEDGE_DEPRECATED_1_34) # pragma message "..."; #endif
This will allow users to disable the warning by defining the macro in their environment.
I would like to extend this to a general policy, to make deprecation more visible were it occurs. Using the BOOST_ACKNOWLDGE_DEPRECATED test we could deprecate libraries or functions, as well as platforms.
The test is a simple 'does this macro exist' rather than testing for a value, so should be compatible with toolchains that allow defining macros, but not giving them values.
The macro is tied to the specific version that is deprecated, so in later releases we should grep for BOOST_DEPRECATED and either update the version, or do something stronger such as use #error (platform) or remove the code entirely (library)
I'm not sure I like all aspects of your proposal, but I do agree that a general deprecation policy would be useful, especially if supported by tools similar to those you envision. 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. This would make it more easy to un-deprecate a platform when it starts supporting the required constructs and enables library authors to accept platform specific patches on a discretionary basis. Moreover even if such patches were not submitted/accepted developers would be free to try and use those portions of a library that do work on their platform. 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. 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? :-). To issue a bugfix release based on 1.32 now probably does not make much sense, but a 1.33.2 release incorporating support for compiler versions issued in the last six months might be appreciated by those wishing to upgrade their compiler separately from their Boost version. Cheers, Nicola Musatti