On Thu, Nov 25, 2010 at 4:29 AM, Matt Benson <gudnabr...@gmail.com> wrote: > > 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? >
<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. Niall > > 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
