Boost logo

Boost :

Subject: Re: [boost] [test] Boost.test failures in develop
From: Jürgen Hunold (jhunold_at_[hidden])
Date: 2015-10-07 06:20:16

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")

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.



* Dipl.-Math. Jürgen Hunold  ! 
* voice: ++49 4257 300       ! Fährstraße 1
* fax  : ++49 4257 300       ! 31609 Balge/Sebbenhausen
*             ! Germany

Boost list run by bdawes at, gregod at, cpdaniel at, john at