Emil Dotchevski wrote:
The whole concept of a library is that it has established interface and semantics that users of the library can depend upon. Without this, libraries are useless. One can't write code based on libraries whose interface and/or semantics are changing without notice.
If that was true, nobody would be using Boost. :)
First of all, most of the boost library authors are concienscious about maintaining the the imutability of the interface and sematics. In part this is due to the fact that boost requires documentation of the interface and semantics. This alone is helpful in diminishing the problem. My complaint is that the testing procedures accomodates silent breaking of interface and sematics - moving the burden from the author making the change to all the users of his library. This is a bad thing and amounts to a breach of trust between library authors and users. It hurts Boost.
It's a fact, Boost libraries evolve and interfaces and implementations change all the time.
Not very often - and when they redefine the original interface and/or sematics they break all user programs (and other libraries which depend upon them). This is a break of
You can argue that the changes are minor, but as you know they're significant enough to break tests in other libraries.
LOL, I'm arguing that they are NOT minor.
For example, the Exception library depends on intrusive_ptr. The only way to make it not depend on intrusive_ptr is to not use it (duh.)
Nope - The exception library should depend upon the intrusive_ptr library interface and semantics which should never change.(duh.)
I am on the fence actually. It was a difficult decision for me, to depend on intrusive_ptr. Ideally it wouldn't change but the reality is that it might. And if Boost Exception wouldn't benefit from a future improvement in intrusive_ptr, it's perhaps better not to depend on it, given how simple it is to "reinvent the wheel" in this particular case.
and your point is? intrusive_ptr interface and sematics might change you shouldn't rely on it? If this is true of course you can't rely on it. THAT's my point. I think we in agreement here.
We have plenty of examples for Boost libraries changing for the better;
LOL - a distinction has to be made between interface/semantics vs implemenation. Implementations can and should evolve. Interface/semantics cannot and should not except in the rarest of circumstances (auto_ptr, vector<bit>).
Boost Function changed between 1.35 and 1.36, both in terms of its interface and semantics. The new allocator support is better but we know it is a breaking change.
If this indeed occurred, it was an error on the part of the author and he's just told users - "you're all working for me now". Not a smart move if he wants to see his library widely used.
Another example, shared_ptr now supports aliasing, which means that other Boost libraries that use aliasing can't be tested against 1.35.
aaaaa - other boost libraries which used alias before it was implemented in shared_ptr. That would be quite a trick. New features an be added to a libray interface and semantics without breaking the old ones. The next version would include new tests and demos and documentation. The next version would depend upon only on those features in existence at the time the extension was written. - unless the library author is psychic.
Had boost::function and boost::shared_ptr been frozen, we wouldn't have been able to make these improvements. If I have to pick between the improvements and the benefits of freezing these two Boost libraries in particular, I choose the improvements (with all the consequences, including release and testing difficulties.)
oh - don't forget about the difficulties of your current users who now have to adjust their apps to accomodate a new library interface. This is an error. If you want new semantics/interface - give them new names and leave the old one's in.
Same with Boost Config: having a single configuration point is convenient but the price of that convenience is coupling.
That is a very high a price to pay and should only be paid in extraordinary circumstances. In this particular case, the change should have been incorporated in the "next release" then it would have been detected when the "next release" is tested. At that point concensus would be built for either backing out the change, or rippling through the interface change to all libraries which depend upon it. During this period - and only during this period - the "next release" would be unstable and not a candidate for a release package.
Yes, but you are assuming that since the period of unstableness is limited in time,
I would be much shorter than the current one.
it's also limited in scope.
That's why it would be shorter time.
For your approach to be practical, we need more formal classification of changes, I think.
We only need two classificaitons: Either a change breaks interface/sematics or it doesn't. Every change fits into one of these two clasifications.
I think that it would work better if we had less coupling in Boost (I'm not sure if that's possible/practical, though.)
LOL - Boost and other libaries are successful in inverse proportion to the coupling to other libraries.
Boost is not a library, it's a collection of libraries.
ALL the more reason for LESS couplilng.
I'm talking about dependencies between Boost libraries, not about Boost depending on external libraries
I'm talking about the concept of libraries in general - of which boost is an example.
(à propos, one of the arguments against using Boost is that it's very difficult to use this or that Boost library without introducing a defacto dependency on all of Boost.)
LOL - avoiding the kind of coupling that our test system encourges is part of this problem.
Suppose STL changed with every release - would it not be effectively useless?
No, but I agree that it would be a lot less useful.
LOL - hmmm alot less useful but better than useless? Care to quantify that?
Also, the price of the stable STL is that we have to live with its problems. A good example is the broken allocator semantics of STL containers.
But at least they're not changing while we're not looking.
Obviously there will be rare occasions when interface and/or sematics of a library change (auto_pointer) when things like design errors are discovered. But these situations should occur only vary rarely.
The question is what to do when such changes in Boost libraries occur,
My proposals effectively separate issues in to two classes. Breakage of interface/sematics and testing of libraries on various platoforms. The current system lumps them together in to one large stew which obsucates the problem and wastes a lot of time.
because the reality is that (very often) they do.
I don't think its that often. Its just that when it does, it creates a big pain in the neck for lots of people ************************ And now while we're at it. The test/build system should be stable during testing as well. Libraries which use the Boost Test shouldn't be using the current "in development" versions to test. This amounts to having all the boost developer's be guinea pigs before the component has been exhaustively tested by the author. The same goes for bjam, process jam log etc. My proposal would also address this since test of each library would occur against only a "known good" set of libraries and tools. Robert Ramey