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