commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...
Date Thu, 25 Nov 2010 12:26:41 GMT
On 25 November 2010 12:01, Niall Pemberton <> 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".


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message