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@wanadoo.fr> 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#Depre... (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