On 12 August 2011 11:19, sebb <seb...@gmail.com> wrote: >> - Removing deprecated methods does not require a package name change > > How so? > > If there are any external references to them in an application that > cannot be removed, then both old and new jars will need to be > deployed. > Which cannot be done safely in a single classloader (no guarantee > which instance of duplicated classes will be loaded). > AFAIK Maven prevents duplicates anyway.
In Joda-Time v2.0 I removed some deprecated methods and left others in (no package name change). Those that I removed were methods that were deprecated for a very long time (probably4years+), with multiple later versions with the deprecation and easy alternates. Those that I did not remove were classes and methods that were probably still in use by people as they were once a primary API. This is a judgement call. And yes, removing a deprecated element means that another project that still uses the deprecation can no longer run. But if you've had something deprecated for over 3 years, that doesn't seem too harsh, unless it used to be a key/primary API. In hard cases, I'd rather see "NewFoo" of "Foo2" replacing "Foo" within the same package name, or a new sub-package within the same o.a.c.codec package space rather than o.a.c.codec2 for everything. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
