Re: [boost] Deprecation and Boost

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-05-07 17:39:12

AlisdairM wrote:
[...]
> Spirit dropped support for 'legacy' compilers a while back.  However, a
> branch of the older version of the library is maintained (1.6, vs 1.8)
> and still tested against boost releases.  Support is still available,
> but separately from the Spirit project, rather than through Boost
> itself.  Robert Ramey shows how this support can be integrated as he
> relies on Spirit support in the Serialization library.

Note however that although it is not made available through the Boost 
website, the 1.6 branch is actually maintained within the Boost CVS 
repository. This is actually what got me started into thinking about 
further bug fix/support enhancement only releases.

> uBlas made a similar choice to stop supporting inadequate compilers
> around 1.32 release.  This is enforced with a #error, and there is no
> workaround.  Generally, users of those platforms are left with a choice
> of dropping their use of the library, or no longer upgrading boost.
> 
> And that problem gets worse when compiler vendors release upgrades that
> are still not supported!  You are left with the choice where upgrading
> your compiler means losing Boost support.

That's the point. For us Borland users there's no way out: it's unlikely 
that we can move on to 1.34 because many libraries don't support our 
compilers anymore and we can only use older releases by applying local 
patches, hoping we're not going to encounter any surprise. The worst of 
it is that just about every Borland/Boost user is going through exactly 
the same moves with few opportunities to share experiences and possibly 
patches.

[...]
> Deprecating a platform boost-wide, rather than on a per-library basis,
> seems the best balance to me.  I know which Boost version is stable and
> tested, I can rely on most libraries in that version, and library
> authors understand what is expected (but not required) of them.  The
> all important recovery-action for the user is simple - install the
> version of Boost pointed at by the deprecation message.

I don't agree. This would work if all the library authors supported the 
same set of compilers. As this is not the case there is no single 
version of Boost that the deprecation message can reasonably refer to.

The real solution for this problem is something that Boost will have to 
face sooner or later and that is breaking the distribution into a set of 
more manageable elements.

> So far Boost has been a remarkably supportive community, especially the
> library maintainers who agreed to one more release to allow a
> deprecation warning.  I think it is equally important we (legacy users)
> help them find ways to move on as well.

That's where a two phase evolution, with .0 releases providing the state 
of the art and subsequent ones with more workarounds and possibly bug 
fixes would prove effective. I am aware, however, that this would only 
be realistic if someone actually volunteered to take on the necessary 
effort.

Cheers,
Nicola Musatti