Re: [boost] Deprecation and Boost

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-05-07 16:53:02

AlisdairM wrote:
> Nicola Musatti wrote:
[...]
> 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.

I agree with the general idea of your proposal; it's the details I 'm 
not convinced about.

>>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.

I'm aware of that. It all boils down to someone volunteering the 
necessary effort *and* resources.

[...]
> 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.

Unfortunately "last supporting release" really means the last release in 
which all the libraries you need are supported. One library moving 
forward is enough to bar you any move forward. Thus it may be the case 
that a small set of workarounds or a new release of your compiler might 
enable you to move forward a few releases.

> 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.

I don't agree. Why remove a support that is there and has been through 
several Boost releases? I understand that library authors wishing to 
evolve their libraries are entitled to choose which compilers they plan 
t osupport and the amount of effort they wish to devote to supporting 
obsolete compilers, but if it works, why break it?

Cheers,
Nicola Musatti