Le 07/10/15 12:20, Jürgen Hunold a écrit :
Hi Raffi,
Most libraries use deprecation warnings like
#if defined(__GNUC__) || defined(_MSC_VER) # pragma message("NOTE: Use of this header (boost/type_traits/broken_compiler_spec.hpp) is deprecated") #endif
at least for whole headers. A simple grep for "DEPRECATION" reveals several libraries using conditional compilation, too.
Hi Jürgen, Thank you for those information. Maybe also transforming the warning into an error after some increment of release...
- apart from public announcement of deprecation, is there currently any other way or good practice for making changes to the public API?
Besides a fat warning in the header, no. Modern compilers support "__declspec(deprecated)" and "__declspec(deprecated(message))" mechanism. Adding support for this to Boost.Config would allow to deprecate single functions etc. That is the way Qt does handle deprecation.
I was expecting some support in boost.config for that for having it clean, but apparently there is nothing.
- if there is a deprecation, what is the amount of time before the deprecated feature is dropped, in terms of releases or years? Is boost clear on that or is it on the hands of the library maintainers? I think it would be good to unify this.
As usual, a maintainer decision. I'd like to have 3 release (aka 1 year) as minimum. Longer periods don't really make sense, as the user base is divided into an "update early" and an "update only in emergency/feature need" partitions. And for the latter even 5 years might be too short...
Ok thanks.
And by the way, can you publish the "boost_run_test" CMake function used in Boost.Test? This would make adapting my own CMake rules easier.
This is an old unmaintained CMakeLists.txt that I should remove at some point. I believe this is pointing to the boost-cmake project. I have my own though, see the branch topic/CMakelist-txt (or commit 8fac3b6 on develop). Raffi