> >> >> [...] > >> >> > >> >> 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
