Re: [boost] [1.51][Release] Short release cycle

Subject: Re: [boost] [1.51][Release] Short release cycle
From: Nevin Liber (nevin_at_[hidden])
Date: 2012-07-01 01:43:10

On 30 June 2012 16:19, Lars Viklund <zao_at_[hidden]> wrote:

> Seriously though, are you proposing that anyone that has to use C++03
> should be locked for all eternity at some ancient Boost version, even
> though there's functionality in newer ones they very much would like to
> use?
>

I don't see how they are stuck on an ancient version of Boost.  It just
means there are some libraries they can't use.

At some point in the future, they will be stuck.  But it will be gradual,
not abrupt.  Just as has been done for those "dialects" (for lack of a
better word) of C++ embodied by gcc before 4.2, Visual Studio before 8.0,
etc., eventually you don't get supported.

> Should we doom a large majority of developers to keep personal patch
> sets against their Boosts, resulting in a largely fragmented and
> impossible-to-handle ecosystem?
>

I don't see how adding C++11 only libraries to Boost has this result.

> I see this primarily from an end-user support and end-user perspective,
> not as any library author or release mangler.
>

What I don't understand is how people who have the ability to upgrade both
Boot boost and compilers (you have to, because Boost periodically drops
support for old ones) don't have the ability to ever turn on the C++11
flag.  (Other than some pathological cases, like having multiple targets
for a product where you have to wait until all your various compilers and
libraries catch up with each other).

It's a burden to target two different languages (even with one being close
to a superset of the other), and I'd rather see C++11 only libraries than
no libraries because that burden is too high.  Because that is the choice
we have to make.

Right now that burden is too high for boost.lockfree.  If that burden gets
lower (by, say, someone so concerned that Boost is going to drop C++03
support that they take over boost.atomic), by all means add C++03
functionality (and I believe the author is certainly willing to do so).

The purpose of C++ standardization is not to fragment the community, but to
grow it and push it ahead.  If it ends up fragmenting, either we didn't put
enough effort into backwards compatibility (blocking people from moving
forward) or way too much effort into backwards compatibility (people just
don't care to move their code bases over to C++11).
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]