While I hardly count as having a vote now, I do have an opinion ;-) I think that the formulation below is too strong. I'd argue that changing the package name is required when there is significant incompatibility, but a major version change might not cause such incompatibility.
For example, if a whole set of new features is added, it can be worth using a new version number for marketing reasons (advertising the major new features). This can result in a major version that is still compatible. It is also possible for a major version to remove just one or two long deprecated methods. In this case, the pain of a package name change is outweighed by the small likelihood of problems. Finally, there are cases where the objects referred to are significant value types that are widely used. In this case, changing the package name is problematic as it causes other libraries that expose those value types onwards to have problems. As an example, Joda-Time may soon have a v2.0. Changing the package name would be necessary if there was major incompatibility. However, in the plan, Joda-Time 2.0 includes Java 5 generics support which is 99% compatible, and the removal of just a handful of long deprecated methods. Furthermore, since many, many other systems use Joda-Time in their APIs, having two versions out there simply wouldn't work. By counter example, having two versions of a standalone utility like StringUtils makes no difference, and having a package name change might make sense in these cases. As such, were I to be voting, I would vote -1. Although I do understand the sentiment, more subtlty is required here - package name changes are sometimes necessary, but must be treated with care. Stephen On 24 November 2010 15:36, 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. > > [ ] +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
