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". --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
