Re: [boost] Deprecation and Boost

From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2006-05-06 04:41:56

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