On Fri, Aug 12, 2011 at 9:54 AM, sebb <seb...@gmail.com> wrote: > 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?
I think we should look at the generics branch (when it is there), make it the best we can, and then consider what it means to binary compatibility and if it is worth achieving. > >> - 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. trunk is codec2 ATM based on the binary incompatibility, due to removed deprecated methods and other changes (field made final for example.) Gary > >> 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 > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
