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