Re: [Libxmlplusplus-general] libxml++ evolution

[murrayc t-online de (Murray Cumming)]

On Fri, 2003-01-31 at 16:32, Stefan Seefeld wrote:
> Murray Cumming wrote:
> > 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. 
> 
> I fully agree. Chances that subsequent commits will fix the regression
> are higher if the person who commits is a core member, i.e. it's somehow
> a question of trust.

That's not relevant in my experience. Core members encounter
difficulties or disappear. Anyway, non-core members don't have the cvs
access to do it anyway.

In general, stuff that is being worked on should be worked on not just
thrown into cvs. Iterative development requires stages, not just a
constant flow. I know you know what I mean, but I like that it can be
expressed. 

> > 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.
> 
> well, as I said, there are parts of the API that are fundamentally 
> incompatible with the suggested change: It's more than a change in 
> implementation if the new code is *strictly* a wrapper around libxml2,
> i.e. doesn't implement itself a DOM tree, but *always* delegates down.

> So strictly speaking, a change like that may be required to be justified
> by a design document. Though that's getting quite a bit formal, and it
> would be the first time in an open project that I see that degree of
> formal development process. (well, actually, I'm trying to encourage
> developers in the fresco project to do just that, as things tend to
> get out of hands at times...:-) But compared to that project, libxml++
> is really small...)

This is all theoretical and never likely to be very relevant in the
real-world. The regressions that your patches introduced seem to be
independent of your future planned changes so no such extreme measures
need to be taken. You have fixed 1 problem and are currently looking at
another. That's good.

-- 
Murray Cumming
murray usa net
www.murrayc.com