On one hand, we have problems that are perceived on the developing side. On another hand, we have problems on the using side -- where lack of any API or ABI stability is surely an important concern -- but solving that concern actually requires more work from developers, and even, I think, more centralization. There's no doubt Debian folks or any other packagers will not be happy about 90 libraries on a separate release schedule.
- Volodya
I think this is very important point. Boost developers are very concern about the amount of work required to maintain the software, but the question, is non-maintained library should be a part of Boost at all? Such huge code-base may become real mess when it is so widely deployed. Let's take a look on a simple example of bug in UUID: https://svn.boost.org/trac/boost/ticket/3971 This bug causes quit not so unique IDs can be generated. This has very bad security concerns that may cause in some software for example guessable session ids. Bad, very bad bug. Security bug. Solution? Upgrade to Boost 1.43 when it is released (with hopefully fixed bug). But lets go to the package maintainers of Linux distributions like Debian: 1. They can't upgrade Boost version because many programs depends on specific Boost version and it can't be transparently upgraded because Boost does not provide neither ABI nor even API compatibility 2. Boost does not release any backward compatible version with at least security bug-fixes. 3. Package maintainers should manually backport all fixes to 1.42 because they have to provide secure software. That is **bad** really **bad**. More then that, I even do not sure if any of maintainers are aware that this issue should be fixed. And this is not distributions issue, many companies stick with specific versions of Boost because upgrade may cost too much. Now, generally the bug I pointed at is not so bad, it has simple fix (fixed in trunk) and it even does not break any compatibility. But: a) What would happen if this issues happens in some unmaintained library? b) Are there any policy of bug-fixes in stable releases? So there are two major issues I see with current development: a) Boost releases should be more modular -- probably single trunk is bad idea. b) Boost should support backward compatibility at some level and incude some maintenance of existing stable libraries. Another point I had figured from reading reviews of the libraries recently was: **Very few reviewers actually do the code review!** Most of them look into API usefulness, documentation of the library but only few of them read the actual lines of code. **This is bad.** For a long time period I was sure that Boost has high quality libraries because may eyes look on them and so all bugs vanish... But it seems to be different. And if we take a look on the situation where: a) Boost is considered high quality set of libraries. b) Boost is very common library and every 2nd C++ project uses is. c) Boost is not backward compatible even and API level. d) Boost does not maintain stable releases. Boost may become a library that when you are using it you are exposed to high risks. My $0.02 Artyom