On December 31, 2012 1:08:36 AM Artyom Beilis <artyomtnk@yahoo.com> 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.