On Nov 24, 2010, at 8:18 AM, James Carman wrote: > On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne > <scolebou...@joda.org> wrote: >> >> 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. >> > > All of these examples would be situations where you'd make the case > that this is an exception, which is allowed by the "rule". >
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. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
