Re: [boost] Release managers: Boost.Thread breaking changes in 1.53

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

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.