commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
Subject Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...
Date Thu, 25 Nov 2010 12:01:43 GMT
On Thu, Nov 25, 2010 at 4:29 AM, Matt Benson <> wrote:
> On Nov 24, 2010, at 2:54 PM, Niall Pemberton wrote:
>> On Wed, Nov 24, 2010 at 7:43 PM, James Carman
>> <> wrote:
>>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>>> <> wrote:
>>>> I disagree. The "rule" should be that a new package and artifactId is required
when compatibility is broken, not when a version change occurs. Exceptions should be based
on that policy, not on a version change occurs.
>>> Ok, so how about we change the rule?  We could say "if the binary
>>> compatibility is broken, then the package/artifactId must change."
>>> Again, this rule can be broken if a component feels they need to do so
>>> and they provide a very good reason. :)
>> How about "if a component decides on a package rename, then the maven
>> artifactId must change"?
> Refresh my memory:  under what circumstances, when binary compatibility has been broken,
would changing the package name *not* be a good idea?

<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


> Can we come to a consensus that we don't want to spend our (in many cases, limited) Commons
development time re-hashing the same discussions over and over again, wherein we try to avoid
the package rename and related tasks, only to conclude in the end, that yet again we need
to do the rename after all?  That is all James is trying to accomplish by bringing this to
a vote.  If this process allows us to establish a general rule, and its effects turn out
to be overkill 0-50% of the time, yet cause no actual harm, then this measure will still be
an undeniable success.
> -Matt
>> If a component breaks binary compatibility and chooses not to do a
>> package rename then changing the maven artifact doesn't help in any
>> way and will just mean additoinal pom config might be required to
>> exclude the old artifact.
>> Niall

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

View raw message