Re: [boost] Deprecation and Boost

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-05-05 03:59:28

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