On Wed, Nov 24, 2010 at 3:36 PM, James Carman <ja...@carmanconsulting.com> wrote: > We've had this package name/artifactId change discussion numerous > times and I think it's time we put this thing to a vote. What I > propose is that we say that this is a rule and in order to "break" > that rule, you have to provide strong evidence that the component's > situation is unique and not affected by the issues that this rule > tries to address. This is to avoid re-hashing this argument all the > time. If a component wants to break the rule, then they should think > through the arguments (read the Wiki page first) and carefully > consider why they feel they are unique and unaffected by the issues. > So, here's the rule: > > A major version change requires that you change the package name (the > part that comes after org.apache.commons) and the Maven artifactId to > the component's name with the major version appended to the end.
Package name change decisions should be based purely on whether a component decides whether breaking binary compatibility is acceptable or not. I also think conflating version/packagename/maven issues causes confusion. The decisions for each influence each, but IMO they need to be considered separately. So -1 from me. Niall > [ ] +1 - accept this as a rule > [ ] -1 - do not accept this as a rule > > Note that we already have a "rule" that says if you're going to break > binary compatibility, you have to change the major version number, so > this rule picks up where that one leaves off I guess. > > p.s. We might also want to propose a rule that says any new releases > of a commons component have to be done in the org.apache.commons > groupId, but that's another issue. > > p.p.s. If anyone cares to restate this rule, please feel free to do > so. I may not have addressed certain "gotchas", but the general idea > is presented. > > --------------------------------------------------------------------- > 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
