Re: [boost] [1.36.0] Libraries with unmerged changes?

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-15 19:13:02

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