Subject: Re: [boost] Release managers: Boost.Thread breaking changes in 1.53
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-12-30 17:19:15
On December 31, 2012 1:08:36 AM Artyom Beilis <artyomtnk_at_[hidden]> wrote:
> 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.
Yes, you are probably right but that is a price that has to be paid to
move the project forward. I'm not referring to the particular changes
in Boost.Thread now, just a general thought. Realistically, API breaks
are inevitable as long as Boost evolves. We can try to reduce the
effect, we can provide compatibility layers but in the end there is
some change that has to be done and which cannot be reasonably covered.
And compatibility layers cannot be maintained forever as well.
I've done a few Boost upgrades in different projects (large and not).
Quite some work has to be done but it's quite doable if the project is
not dead. If it is - who cares.
> 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.
No disrespect to Linus but I can't say I agree with his strong position
(and especially with his communication style, BTW). Bugs must be fixed
where they are, be that kernel or userspace. Trying to cover them only
makes things worse in the long run. Again, it's my opinion in general
and not about the particular issue the quote is taken from.
> There should be VERY STRONG reasons for breaking API, not just because new
> iterface is much better.
Agreed, if the new interface can be provided alongside with the old
one. Deprecation periods are for this.
> This reminds me other discusstion I started:
> Â http://thread.gmane.org/gmane.comp.lib.boost.devel/237276
> About security fixed and updates on which I got no reactions...
Personally, I would like to see that happen. Am I ready to make that
happen? I don't think so. Releasing Boost is a hard work which includes
testing, documenting and Release managers know what else. I'm not
prepared to do that for point releases. As a user, I'd rather upgrade
my projects to newer releases of Boost or particular Boost libraries,
it's not a big problem to me. As a library developer I would probably
backport critical bug fixes to previous releases but that still leaves
a lot of work to actually release them and apparently noone has the
resource for that.
> 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
I think you exaggerate. Boost is clearly used in many projects,
including big ones and upgrade costs are coped with.
To make things clear. I'm not saying that the API breaks are good; they
are not. It's the necessary evil to move forward. And if the project is
not moving, it is dead.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk