Re: [boost] Release managers: Boost.Thread breaking changes in 1.53

Subject: Re: [boost] Release managers: Boost.Thread breaking changes in 1.53
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-12-31 06:11:52

On Dec 31, 2012, at 4:31 AM, james <james_at_[hidden]> wrote:

>> All depend on what do you intend by significant added value. From my POV the std thread was designed more carefully than Boost.Thread which was the implementation of one of the first proposals. The implementation was just frozen until the standard was fixed.
> 
> What is the point of changing boost::thread to behave like std::thread?

He gave one reason above: he thinks std::thread an improvement.

> The user can already choose to use std::thread behaviour - by using std::thread.

That's only possible with a conforming C++11 implementation, which may not be available for years, especially to those writing cross-platform code.

> Surely it makes more sense that where boost has implemented something that has made it to the standard, that the boost implementation be frozen and deprecated and that the compiler runtime version be preferred for new development?  And that projects move to std::thread?

Where Boost's implementation differs significantly from C++11's, it certainly can make sense for Boost to provide both its original and the new behavior and interface. However, Boost is a volunteer organization and maintaining one version of a library is often sufficiently taxing.

Another's suggestion to allow 2-3 years for deprecating features or to transition to new behavior is likewise asking much of a volunteer, though I'll grant that three quarterly releases is a rather short time by the calendar.

> That should apply to the smart pointers as much as thread, and possibly others too

Obviously, if some volunteer to maintain the old, while others add and maintain the new, it is possible for Boost to have its original and a portable C++11 variant of such libraries.

___
Rob