On 12 August 2011 16:08, Gary Gregory <garydgreg...@gmail.com> wrote: > 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.
Again, it would be easier to evaluate the branch if it uses the same package name. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
