On 25 November 2010 12:01, Niall Pemberton <niall.pember...@gmail.com> wrote: > <slightly OT> > IMO changing the package name is always a bad idea and I think we have > been too quick to do it, rather than trying to retain compatibility. > Its effectively starting a new component and perhaps merited on rare > occasions - but I think we have been two quick to dump whole > components rather than look at more localized solutions at the > individual class or package level. > </slightly OT> > > Commons Validator has broken binary compatibility in the past with > zero impact that I know of. It depends on how widely used the > component is and the nature/scope if the break. > > We have a general understanding that our widely used components will > not break binary compatibility (e.g. lang, logging, beanutils) but > other than that there is no commons wide policy that we will never do > so and its a decision for each component to make on the merits of the > situation.
This was the point that I was making earlier. Changing the package name is a BIG deal. It should be used as a tool of last resort, but when necessary it is essential. Removing deprecated methods is binary incompatible, yet doesn't require a package name change. Changing the signature of a method judged to be rarely used probably doesn't require a package name change. Breaking binary compatibility in any component that isn't that widely used probably doesn't require package name change. Components of mostly utilities - [lang] and [io] for example - can change package name more easily than those where the classes are exposed in other APIs - [collections] and [logging] for example. But again, package name change, like binary incompatibility is to be avoided wherever possible. Here is my rule: "if the binary compatibility is broken in a significant way, then the package/artifactId must change, however all binary incompatibility should be avoided wherever possbile". Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
