On 17 August 2012 16:44, Gilles Sadowski <gil...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
