Boost logo

Boost :

Subject: Re: [boost] Release managers: Boost.Thread breaking changes in 1.53
From: ecyrbe (ecyrbe_at_[hidden])
Date: 2013-01-03 12:31:21

2013/1/1 Rob Stewart <robertstewart_at_[hidden]>

> That leaves only four options for Boost:
> 1. Ignore C++11 compatibility.
> 2. Provide exactly C++11 API and behavior.
> 3. Provide 2 plus pure extensions.
> 4. Provide both 1 and 2 via two namespaces or classes.

If vincent wants some users opinion, I'm all for option 1 or 4. I know that
option 4 is a maintenance nightmare, so sticking with option 1 is fine for

I'm concerned about distribution maintenance. Boost.Thread is not a header
library. so it is packaged once for all applications in a linux
distribution (like debian).
breaking compatibility on a header only library is not a problem, but for
the other few dynamic libraries of boost, breaking compatibility is a big
deal beacause you can't have control.

One application might still use the old behaviour, as the other using the
new one. this can't be solved using a macro definition. using a macro would
be a distribution patching nightmare. more than the boost distribution cost
of maintaining two distinct namespaces for old and new behaviour.

For boost maintainers, i know that it's a really hard job to maintain a
library. But when releasing a dynamic library for boost you should keep API
and ABI backward compatibility if you announce that you support linux. I
know a lot of the maintainers only care for windows or mac and have a point
of view that the application developper is in charge of his software
dependancy and build tool chain... but it's not true in linux domain.
please keep it in mind.

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