On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne <scolebou...@joda.org>wrote:
> While I hardly count as having a vote now, I do have an opinion ;-) > Cycles welcome :)) > > 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. > I have been worrying about this re [pool] where we made the decision to repackage for 2.0. My perhaps naive assumption is that users who are just using the interface definitions or constants can continue to depend on the 1.x versions. Do you see a problem with this? > > 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 > >
