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
me.
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.