Boost logo

Boost :

Subject: Re: [boost] Release managers: Boost.Thread breaking changes in 1.53
From: Brian Ravnsgaard Riis (brian_at_[hidden])
Date: 2012-12-31 21:45:46

Den Sun, 30 Dec 2012 22:08:36 +0100 skrev Artyom Beilis
> Probably I would find myself in minority or hated by many Boost
> **developers** but
> I would say clearly that there are hundreds thounds of C++ developerds
> and thousands of project that break because Boost breaks API.
> HUGE amount of man hours are spent just because Boost breaks stuff.
> I would like to provide a recent quote of Linus Torvalds regarding the
> kernel:
> > WE DO NOT BREAK USERSPACE! Seriously. How hard is this rule to
> understand?
> > [...] The fact that you then try to make *excuses* for breaking user
> space,
> Of course Boost is not Linux kernel, (if Linux kernel was managed as
> Boost I would
> switched to FreeBSD) and it not as important to maintain backward
> compatibility
> from user perspective, but this is something we MUST learn.

I disagree. As a boost user!

> There should be VERY STRONG reasons for breaking API, not just because
> new
> iterface is much better.

Again, I disagree. One of the purposes of boost has always been to break
new ground, to the point of submitting existing libraries for
standardization. This is quite unlike *any other* c++ library out there.
Sure, others occasionally do the same, but it is in boost's core values,
so to speak.

That said, I think a reasonable transition should be available. I'm not
advocating breaking things, just because we can. If a library maintainer
comes up with a better interface, it would be very nice to provide the old
one as well for some releases, probably as default first, then as backup
next, before it's finally removed. Obviously, if the compiler could be
persuaded to give warnings as well that would be even better. But none of
this should limit the flow of *progress*. We *want* to see how new
interfaces can work!

> This reminds me other discusstion I started:
> About security fixed and updates on which I got no reactions...
> Bottom line:
> - Boost does not provide fixes of critical bugs, for stable released
> - Boost does not provide security updates for stable released
> - Technically boost does not maintain stable releases at all
> - Boost breaks API.
> So how can it be used in some long running projects?
> The answer it can't, you either stuck with a release with huge holes
> and critical bugs or you break your software trying to upgrate
> and keep up with some new progressive and great idea some library
> brings.

I think (though I've not fully studied the fine print here) that this will
become easier in the modularized boost.


> This is just a sad reality

It's a consequence of the current model and the core purpose of boost.


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