|
Boost : |
Subject: [boost] Any Chances for Boost Stable?
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-01-21 06:35:17
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk