On Fri, Aug 12, 2011 at 11:42 AM, sebb <seb...@gmail.com> wrote: > 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.
Yes, I'll do it that way :) Gary > >> 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 > > -- 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
