Deprecation of compilers and libraries
Hi, It seems the acceptance of Phoenix V3 has raised the question on how to handle the deprecation of compilers and libraries again. I believe it is important to reach a consensus and to make an official statement regarding it, as it's important for both users and developers. Below I've assembled a set of questions I would like to see answered: Compilers: 1. What minimum of compilers should a library support for it to be considered for review? 2. What is necessary for a compiler previously supported to be removed from this list? Libraries: 3. Should library X be marked as preferred over library Y, since multiple solutions to a similar problem are becoming more common and the right choice might not be obvious to a user? 4. Can an existing library be marked "deprecated"? 5. Once deprecated will a library be removed from boost after X releases? 6. Should a backwards compatible solution exist for a library to be removed? Personally I believe dead branches should, in due time, be cut from the tree for boost to remain at the forefront of C++ development. Especially now the number of libraries is growing, we should aim for clarity. Regards, Jeroen Habraken
On 17 March 2011 21:04, Jeroen Habraken <vexocide@gmail.com> wrote:
Compilers: 1. What minimum of compilers should a library support for it to be considered for review? 2. What is necessary for a compiler previously supported to be removed from this list?
See: http://www.boost.org/development/requirements.html#Portability No compilers are explicitly listed, but Gcc and Visual C++ are clearly the most important, since they're the dominant compilers on unix and windows systems. People seem to be taking up Clang quite rapidly as well.
Libraries: 3. Should library X be marked as preferred over library Y, since multiple solutions to a similar problem are becoming more common and the right choice might not be obvious to a user?
IMO, no, unless the maintainer wishes to do so.
4. Can an existing library be marked "deprecated"?
Yes, it's happened before: http://www.boost.org/doc/libs/1_46_1/libs/compose/
5. Once deprecated will a library be removed from boost after X releases? 6. Should a backwards compatible solution exist for a library to be removed?
There's no policy on that. I'm not sure there should be since it can vary from library to library. Classic spirit is pretty much deprecated but they keep it around (and I'm glad they do). While filesystem v2 is going to be removed, which seems sensible because the upgrade path is fairly easy. Daniel
On Thu, Mar 17, 2011 at 11:25 PM, Daniel James <dnljms@gmail.com> wrote:
4. Can an existing library be marked "deprecated"?
Yes, it's happened before:
I guess the Boost.Bind docs, in the section "Using nested binds for function composition", should be updated not refer to Compose? - Rob.
participants (3)
-
Daniel James -
Jeroen Habraken -
Robert Jones