Emil Dotchevski wrote:
You're arguing that we mustn't be making breaking changes,
I've noted that some boost authors make breaking changes. I'm arguing: a) the current test system doesn't segregate breaking from non-breaking changes This causes a lot of extra work for developer's trying to test their code. b) the current test system requires that all developers be "in sync" to get a release together. This becomes more and more difficult as the number of libraries increases. c) the current test system does nothing to discourage breaking changes. this diminishes the quality of boot libraries and moves work on to library users. My proposal would: a) save a lot of wasted time looking for problems which in fact are side effects of some un-anounced breaking changes. b) make better use of boost test resources by running tests in a controlled manner rather than testing on a moving platform. c) Improve boost by discouraging breaking changes. d) Improve boost by usually having ready the "next release" thereby short circuiting calls for "point releases, etc"
and I'm saying that sometimes we do make breaking changes.
and this is not an argument against my proposal - in fact, since my proposal results in a system which distinguishes these changes and explicitly brings them up as an issue to be addressed by concensus. That is, my proposal recognizes this issue rather than ignore it as the current system does.
These changes haven't made Boost less useful for me, on the contrary -- I welcome the improvements.
Of course every library author makes his choices here. If he does this, he risks alienating users - but that's his choice to make. In the history of the serialization library, it has occurred a couple of times where changes in dependent libraries broke something and I was left to scramble to accomodate the ripple effect. Worse - since this occurs on Boost's schedule rather than my own it's even more inconvenient. On one occasion this occurred with a component of significant size. I just couldn't see signing up for a life time job so I just re-implemented the functionality inside the serialization library. I huge pain, but better than picking up after someone else for the rest of my life. I don't think the impact of this kind of thing is always appreciated. Robert Ramey
We need a system that can deal with this reality.
Which is exactly the problem with the current system and the motivation for my proposal. Robert Ramey