Any Chances for Boost Stable?
Hello, This mail is rather discussion of possible future Boost policy rather then concrete features it provides. Is there any chance for Stable Boost version? --------------------------------------------- What do I mean stable? Stable as Qt4, stable as STL Port, or STL. Boost is one of the greatest platforms for development of bleeding edge technologies. Like Boost.Asio is one of the greatest Asynchronous API libraries. On the other hand, this library is extremely unstable: each release breaks compatibility with previous one! When I compile a program or library that uses STL I expect that it would continue to work as long as compiler keeps table ABI (GCC - for years). I can compile great GUI application with Qt and expect from it to work for years and be sure that core Qt library includes updates, bug fixes and so. I can't do it with Boost! -------------------------------------------------------- Is there any chance to create a stable Boost branch that includes: - All libraries included in Tr1 - Various other stable libraries. This branch would keep: stable API and ABI, It may include additional libraries and features as long as they do not break API/ABI. Adopt the code such that different changes would not break ABI. For example, if shared_ptr on specific platform uses mutex or atomic counter, it would not be changed withing release because of new supported feature -- meaning config.hpp should be recompiled similarly as it done with autotools. Adopt pimpl policies of Qt to make sure that classes can be easily extended without breaking them. ------------------------------------ I know that this is lot of work and this is totally different from current Boost policy. But Boost should not be only experimental library... It should be as stable as STLPort or STL. -------------------------------- Do we need Boost.Stable branch? -------------------------------- Artyom
Artyom wrote:
Is there any chance for Stable Boost version?
My guess? No. First, you can have your own stable version by not moving to the latest release. You can even apply patches to earlier releases to pick up bug fixes added to later releases. That puts the onus on you, of course, and that means you miss out on new libraries, but it works. Second, to have a stable Boost branch requires more maintenance effort by library maintainers. Since the focus is always on the next release, what with adding new features and refactoring designs -- the fun stuff -- you can imagine back-porting patches would not be a high priority. There could be, I suppose volunteers to be maintainers of each library in the stable branch, but I doubt many of the current maintainers will be among them and I doubt there will be enough volunteers to make the effort viable. Is that too pessimistic? Maybe, but I suspect it is just realistic. Third, to manage a stable Boost branch requires a separate test and release process which requires still more resources. It's hard enough getting the necessary resources for the normal Boost releases. It doesn't seem likely to double them. Various Linux distributions offer their own take on stable Boost versions. Folks go through a great deal of effort to create versioned Boost packages. I suspect some even apply patches to earlier versions. That doesn't help Mac OS or Windows users, of course. I don't doubt the utility or desirability of stable Boost releases, but I don't think they are likely. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Thu, 21 Jan 2010 08:26:57 -0500, "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
I don't doubt the utility or desirability of stable Boost releases, but I don't think they are likely.
I agree with you, I however would like to point out that if you stick to stable libraries within Boost, the upgrade path is not that expensive. I'm not sure it's reasonable to expect commercial-grade support for an open source library. Maybe one could think about building a business based on providing companies with that kind of "boost stable" support. -Edouard
edouard@fausse.info wrote:
I agree with you, I however would like to point out that if you stick to stable libraries within Boost, the upgrade path is not that expensive.
Sometimes it is very expensive, or even impossible. Like Boost.Graph and Boost.Variant being incompatible since 1.41 : http://lists.boost.org/boost-users/2010/01/55317.php I don't know if you consider Graph and Variant as 'stable libraries' though. -- Maxime
2010/1/21 Stewart, Robert <Robert.Stewart@sig.com>
Various Linux distributions offer their own take on stable Boost versions. Folks go through a great deal of effort to create versioned Boost packages. I suspect some even apply patches to earlier versions. That doesn't help Mac OS or Windows users, of course.
My suggestion is Boost.org is just getting support from port maintainers for various operating systems. I guess UNIX-like are most important ones, since they often use a repository for applications. For example, for FreeBSD we do not update to the next release until we patch Boost enough for all dependent applications to compile and run. What I prefer is boost.org folks do not just compile boost on FreeBSD (OpenBSD, OS Y, whatever) in an own way and say "Hey, it works on that OS!", but just wait for all port maintainers to confirm the libraries are good enough to go into the release. Of course, this may make release cycle longer for a couple of weeks, but the stability worth it. The great number of dependent applications getting re-built with the updated boost libraries may even detect some binary incompatibility issues. So then, just outsource some testing and you'll get both source compatibility and binary compatibility reports virtually for free. Sincerely, Alexander Churanov, maintainer of devel/boost-* for FreeBSD
Artyom wrote:
Hello,
This mail is rather discussion of possible future Boost policy rather then concrete features it provides.
Is there any chance for Stable Boost version? ---------------------------------------------
What do I mean stable? Stable as Qt4, stable as STL Port, or STL.
Boost is one of the greatest platforms for development of bleeding edge technologies. Like Boost.Asio is one of the greatest Asynchronous API libraries.
On the other hand, this library is extremely unstable: each release breaks compatibility with previous one!
I find that Boost libraries almost never break compatibility with a previous version so I judge your assertion to be incorrect. Care to give evidence for what you say ?
Artyom wrote:
Is there any chance for Stable Boost version?
Boost is a collection of libraries with different characteristics. The best that we can hope is that each individual library declares that it is, for example: - Stable, because it's a completed implementation of e.g. a tr1 or c++0x feature that's not going to change. - Stable, in the sense that new features will be added and old stuff at worst deprecated (e.g. Spirit and its "classic" branch). - Unstable, because it's a new library that's still evolving. - Bah humbug this library maintainer doesn't want to tell you if it's stable or not so you can assume the worst :-) It would help for the docs to spell this out explicitly, but I think most of us can probably guess the answers for the libraries that we use. I have some experience of distributing source code that depends on Boost, and there is an issue here. It's not reasonable to depend on a single version of Boost since distributions only package -dev packages for one version, which could be too new or too old. As a result I tend to avoid dependencies on libraries that I suspect are unstable in this sort of code. There is much less of a problem if you either rely on distributions to establish compatibility or if you distribute binaries. Regards, Phil.
2010/1/21 Artyom <artyomtnk@yahoo.com>:
When I compile a program or library that uses STL I expect that it would continue to work as long as compiler keeps table ABI (GCC - for years).
Maintaining binary compatability in C++ requires great effort and has performance implications, so I don't think it's reasonable to ask for it. Much of boost does tend to be source-compatible between versions, though.
Maintaining binary compatability in C++ requires great effort and has performance implications, so I don't think it's reasonable to ask for it.
The performance implications are quite neligable, similar to usage of virtual functions, on the other hand, it even may improve performance because of smaller size of executable... But this is not the point; Nobody says keeping ABI is simple, especially when the library is not designed for it. However, if you do design it correctly, with all "d-pointers" needed to extend the functionality in future, it is not so hard.
Much of boost does tend to be source-compatible between versions, though.
Unfortunaly this is not enought. The problem is that Boost today is what JDK for Java. What would happen if every sinlge JDK minor release would require developers to compile version for specific JDK or user have all minor releases installed. What would happen to Qt or GTK if they were not keeping their ABI? Bad things. So what I call is to look at Boost as we look on Qt/GTKmm/JDK because it is not less important then other great libraries that do the right job. Artyom
Zitat von Artyom <artyomtnk@yahoo.com>:
Maintaining binary compatability in C++ requires great effort and has performance implications, so I don't think it's reasonable to ask for it.
The performance implications are quite neligable, similar to usage of virtual functions, on the other hand, it even may improve performance because of smaller size of executable... But this is not the point;
Nobody says keeping ABI is simple
it´s not practical for templates and impossible in some cases. example for not pratical: Boost.Intrusive changed the return type of intrusive::unordered_set::erase from iterator to void. for most use cases, this does not break source compatibility, but binary. using a virtual function or similar for Container::erase is not practical. example for impossible: Intrusive also changed the return type of unordered_set::erase_and_dispose, which is a template function.
The problem is that Boost today is what JDK for Java. What would
Java/JDK has generics and an inlining JIT-compiler.
participants (9)
-
Alexander Churanov -
Artyom -
edouard＠fausse.info -
Edward Diener -
Maxime van Noppen -
Phil Endecott -
Scott McMurray -
Stewart, Robert -
strasser＠uni-bremen.de