Subject: Re: [boost] [thread] Do we need thread_group now?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-14 20:22:10
Le 14/04/12 22:09, Olaf van der Spek a écrit :
> On Sat, Apr 14, 2012 at 11:28 AM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> I don't know it adding these simple algorithms would be useful to the Boost
>> community if thread_group is deprecated. I could live without them, my main
>> concern is to deprecate thread_group.
>> What do you and others think? Anthony?
> Does Boost have guidelines for deprecation / backwards compatiblity?
> What's the point of deprecating this stuff?
there are no official guidelines. You can look at
(last modified 2 years ago) that gives some ideas.
My idea of deprecating a feature goes on 3 stages:
* 1st. The feature is announced to be deprecated. The features is
available by default. If possible the deprecated features are moved to a
new file so that a warning is reported when this file is use. Users can
configure the library at the header level so that the deprecated feature
is not available and the warning removed or just request the warning to
be removed but let the feature available. This allows preventive users
to switch to the alternative path. Maintenance continue.
* 2nd. The feature is announced as deprecated. The features is NOT
available by default. Users can configure the library at the header
level so that the deprecated feature IS available. This alert not
preventive users that the feature will be removed soon, as the program
doesn't compile without a change on the configuration. Maintenance is
* 3rd. The feature is removed so NOT available at all.
I think that a period of 9 month/1 year between each stage is a good
compromise. That lets 18 months/2 years to switch between the announce
and the removal. This let also the time to see if the alternative is a
real one. The period could be extended if the change is large.
The thread_group class could be in this case and two periods of 9 month
could be enough.
A different history occurs when the feature is not removed but changed,
the library is not header only and the feature is implemented on the
.cpp files. Here two more stages can be considered and not always possible
* 0th. Move the feature out of the .cpp files, so that it could be
configured without rebuilding the library. Note that the .cpp files
could not use this feature.
* 3rdbis. The old behavior of the feature is removed so NOT available at
* 4th. The new feature could be moved to the .cpp files.
E.g. I have started to implement some breaking changes on Boost.Thread
as e.g. an incompatibility with the C++11 semantics of the thread
destructor. Boost.Thread detach the thread at destruction time, C++11
calls std::terminate if the thread is joinable at destruction time. I
have already started the stage 0th and I would like to pass to the stage
1st for the next release.
Of course before deprecating a feature we need to be sure that an
alternative is widely available. An example of this case are the time
related functions of Boost.thread. Next release will include the
chrono-based interface that will be the alternative. But there is at
least a compiler that don't support Boost.Chrono at all (vacpp). So
deprecating the old time based functions could not be acceptable for
people that uses this compiler as they can not replace it.
When the change has a deep impact on the interface, design and/or
behavior, a new version with a different namespace should be considered.
I'm sure others have more ideas on how to deprecate a feature.