Robert Ramey wrote:
Nicola Musatti wrote: [...] Here is an example of a system that would implement the testing required by Beman's proposal. I' m not proposing this system but I am just demonstrating that it is possible.
[Reasonable scheme snipped] I see. A developer might have to wait a while for tests to happen, but there should be a gain in terms of much reduced confusion with respect to how things work now. And once tests pass s/he is guaranteed that s/he is done with that specific change.
So, the decisions about what to test and when to test it are handled "coordinated" without requiring developer's and testers to work in lockstep. Each library can be developed independently at its own pace.
Provided the queue doesn't grow to much. But then that would only mean that testing resources are insufficient, and there's very little that can be done about that apart from adding some other. [...]
I have concluded that breaking interfaces is a bad thing for users. It is a breach of trust between the library developer and library user. I presumes that users have nothing else to do but constantly tweak their own code to keep up with the libraries changes. This defeats the whole purpose of using a library in the first place. Library developers who do this will lose "customers". We have already seen examples of this. Having said that, boost library authors have been pretty good about not breaking interfaces so I don't think this will be a huge problem in practice.
I understand your feelings, although one could say that designing interfaces in view of standardization is one of Boost's goals. The Boost libraries are experimental, in a way. [...]
User code is already written and running. Suppose there are 1000 users of the serialization library. Suppose I were to make a change for 1.34 that would require all those users to investigate their code and tweak it because I made a change? Do you really think that would be OK?
Not unless there was a lot to be gained by the change. And even then what is a lot for someone is likely to be totally irrelevant for someone else.
I don't think users would appreciate the introduction of duplicated functionality in family of libraries that, rightly or wrongly, is perceived as a mostly coherent whole.
Now that is the central question. "mostly coherent whole" highlights the issue. I would guess that when boost started out, the "model" that was envisioned was STL which is a very coherent whole. I think experience has shown that such a vision is a chimera and no amount of work will make such a vision reality.
The next best thing (actually a better thing) - is a large set of decoupled libraries which have stable interfaces. Note the by "decoupled" I don't mean that a library should not depend upon another library but rather it should depend only upon its document interface.
Oh, absolutely! Common functionality across libraries should always emerge in the form of, possibly small, additional libraries. There shouldn't be a common 'detail' directory.
The best thing that boost - and only boost - can do is to use its review process to promote/enforce. a) conceptional integrity - libaries which do one thing at a time without mixing up bunch of orthogonal functionality. b) well defined and well documented interfaces. c) quality implementation d) quality documentation
library "unit testing" against the released library enhances these goals.
I agree.
[...]
In my opinion flexibility stems from the fact that with a much shorter release cycle skipping one is not going to be such a big deal, so developers will be faced with reasonable alternatives. For that to happen each cycle must be managed very rigorously. That's whats causing the current difficulty. Working harder at it will just make it worse. This is where we disagree. I keep thinking that if self discipline were enough, there wouldn't be problems right now.
I agree - its not about self discipline. Its not that people aren't working hard enough. As I said, working harder won't help. Its that we're doing the wrong thing.
I still think I have to see it working to be completely convinced, but I'd welcome being proved wrong :-) My only remaining question - not specifically to you, Robert - is how is this whole thing started? Cheers, Nicola Musatti