On Nov 24, 2010, at 2:54 PM, Niall Pemberton wrote: > On Wed, Nov 24, 2010 at 7:43 PM, James Carman > <ja...@carmanconsulting.com> wrote: >> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers >> <ralph.go...@dslextreme.com> 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. -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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
