Re: [boost] [thread] Do we need thread_group now?

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?
>
>
>
Hi,

there are no official guidelines. You can look at 
https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#Deprecatingfeatures 
(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 
stopped.
* 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 
all.
* 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.

Best,
Vicente