Re: [boost] Deprecation and Boost

From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2006-05-06 05:26:15

Roland Schwarz wrote:

> While I think deprecation announcement is useful in general, current 
> practice possibly is too restricting. What I would rather like too
> see is a library component specific deprecation.
> 
> Why should e.g. support for threading lib for an old compiler where
> it was known good be deprecated? In my opinion the respective library 
> maintainer should be in charge of warning the user that the library
> is evolving into a direction where support of a specific compiler
> will be dropped in a future release. Doing this at a global scope
> does not allow this.
 
> What do you think?

See Russel's comments elsewhere in this thread.
The problem is that once support for any library is removed, it is
harder to move forward to another Boost release even if all the other
libraries you use are still supported.  There are a couple of
precedents for this already.

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.

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.

At the moment this would only seem to affect the Borland community, as
the other compilers being dropped are long replaced by better supported
compilers.  Borland are still working on a compiler that has more bugs
than library maintainers are comfortable supporting.

Given the limitted volunteer resources that make up a FOSS project like
Boost, I am trying to find the best balance for all involved - library
authors, users of older compilers, and users of new compilers who don't
see the benefit of all that legacy support.

[Simply telling people working with old compilers they are idiots and
should upgrade is not very helpful - there are MANY reasons people get
stuck with tools they would rather replace, often the decision is not
their's to make]

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.

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.

[Clearly there is no issue for new libraries choosing not to support
legacy compilers, the problem is in dropping existing support]

-- 
AlisdairM