Re: [Libxmlplusplus-general] libxml++ evolution

[<mu...@t-...>]

On Thu, 2003-01-30 at 17:47, Stefan Seefeld wrote:
> However, I don't agree that individual checkins must not generate
> regressions. Sometimes changes are quite complex, and imply more than
> just an implementation fix.

Rejecting regressions is a reliable way to ensure that the code doesn't
stay broken. Half-finished changes have significantly delayed or killed
projects in the past. It's OK if you are going to fix-and-simultaneously
improve things with your next check-in in a few minutes. 

But taking the current patch as an example, if we don't check that it
works then we _might_ discover later that we've made a fundamental
change which can _never_ support even the old functionality. And, after
all, the other patches that you've suggested are additions to the API,
so it won't be any waste of time to make sure that the existing API
still works with the patch.

However, it's not too bad to submit incomplete candidate patches and
gradually revise those patches until one is fit for a commit.
  
> I think it's much more easy to make
> the transition incrementally, accepting that the code will temporarily
> contain regressions, as long as they are well known and tracked.

Incremental development is great, and I will always demand it. But that
doesn't require regressions in most situations.

-- 
Murray Cumming
mu...@us...
www.murrayc.com