Hi Raffi, Am Dienstag, 6. Oktober 2015, 11:11:16 schrieb Raffi Enficiaud:
Talking about planning, I would like to know
- what is the policy of boost wrt. deprecation warnings? My opinion is that deprecation warnings, either from the compilation perspective or usage (eg. from the command line) is the best way to push the changes on the end user side. But I do not know what boost says about that. On boost.test side, we want to deprecate some headers, function and macros, as well as runtime arguments.
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.
- 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.
- 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... Just my 0.02€ 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. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany