On 12 August 2011 14:33, Gary Gregory <garydgreg...@gmail.com> wrote: > Can we proceed like so? > > - I'll save my generified codec in an svn branch ASAP. > - we can discuss that and get the best design > - is it binary compatible?
Or can it be made binary-compatible without excessive compromises? > - if not, which is my current view, then package is codec2 Whatever the final decision, it's much easier to keep the package name as codec until just before release. > We have lang3 and digester3 under our belts now with new packages. Are > we going to change policy again? I hope not. We sure spent a lot of > time on this and thought we made a sane decision as a community. > Joda-time is its own world can do what it wants but I'd like to keep > my sanity in commons land with clear and consistent policies ;) It's not a change in policy; lang3 and digester3 are exceptions. > Wrt to removing deprecations, we can revisit each change one at a time > if someone cares to data mine svn for the age of each or whatever > metric you want. +1 > Cheers to all and thank you for your time and constructive feedback :) > > Gary > > On Aug 12, 2011, at 6:31, Stephen Colebourne <scolebou...@joda.org> wrote: > >> 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 >> > > --------------------------------------------------------------------- > 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