commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Math] Cleanup in "HarmonicFitter" and "GaussianFitter"
Date Fri, 17 Aug 2012 15:52:43 GMT
On 17 August 2012 16:44, Gilles Sadowski <gilles@harfang.homelinux.org> wrote:
>> >> >> [...]
>> >> >>
>> >> >> 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.
>

My point was that it's still a risk assessment.

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

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


Mime
View raw message