On Fri, Aug 12, 2011 at 10:35 AM, sebb <seb...@gmail.com> wrote: > On 12 August 2011 15:29, Gary Gregory <garydgreg...@gmail.com> wrote: >> 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.) > > Yes, if released as binary incompat. it will have to change to codec2, > but the package change can (and IMO should) be left until the last > moment. > > As it stands now, it's much harder to check for binary compat (have to > use shade before using clirr). > Also, if it turns out to be possible to maintain binary compat, the > name change will have to be reverted.
Ok, I'll revert the codec2 change after I save my generics branch, hopefully later today or this weekend. Gary > >> 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 >> >> > > --------------------------------------------------------------------- > 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
