commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...
Date Thu, 25 Nov 2010 04:29:49 GMT

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?

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.


> 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:

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

View raw message