commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Cleanup in "HarmonicFitter" and "GaussianFitter"
Date Fri, 17 Aug 2012 15:44:31 GMT
> >> >> [...]
> >> >>
> >> >> In other cases, it may turn out that the chance of 3rd party code
> >> >> using a class is vanishingly small.
> >> >> In which case it should be OK to break compat.
> >> >
> >> > What is "vanishingly small" here?
> >>
> >> That the likelihood of it being used is very small, based on what the item does.
> >>
> >> It's a risk judgement to be made by the developers - no hard and fast
> >> rules here.
> >
> > There are changes we didn't perform on "equally" vanishingly small issues
> > (e.g. changing the value of a "public" default tolerance).
> > According to what you say here, we could have run the risk of changing those
> > "little" things.
> > But what if someone then complains (_after_ the release that breaks
> > compatibility)?
> >
> > Sorry, but it does not make sense to have to make those "risky" judgements
> > whereas we can just make more releases (minor do not break anything, major
> > can break anything).
> > It does not make sense because it leads to discussions about how significant
> > a change is, which is completely subjective.
> >
> > It does not make sense because, if someone used the code, say intantiated
> > the "HarmonicFitter.ParameterGuesser", and we now make it disappear, there
> > is a 100% chance that his code will be broken. For him that's not exactly
> > vanishingly small. ;-)
> 
> Of course not.
> 
> But making the change as part of a major version bump with associated
> package and Maven groupId changes affects everyone who wants to
> upgrade Math.
> Fine if there are other changes that really require such a break, but
> not so fine if there are only minor incompatibilities that may not
> affect anyone.
> 
> I'm just trying to point out that there may be cases where it's worth
> the potential risk of breaking someone's code.

I totally agree. There are quite a few places where (IMHO, of course) it's
worth the risk. But I came to the conclusion that most people here want to
be on the safest side, and hence that it's not worth to start a discussion
on breaking compatibility since there is a vanishingly small probability to
not raise a -1. :-)

> 
> Fixing a long-standing bug may break some code if it has come to be relied on.
> 

But that's another kind of compatibility break.


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message