commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [codec] getting the bmpm code out there
Date Fri, 12 Aug 2011 15:53:18 GMT
On Fri, Aug 12, 2011 at 11:42 AM, sebb <sebbaz@gmail.com> wrote:
> On 12 August 2011 16:08, Gary Gregory <garydgregory@gmail.com> wrote:
>> On Fri, Aug 12, 2011 at 10:35 AM, sebb <sebbaz@gmail.com> wrote:
>>> On 12 August 2011 15:29, Gary Gregory <garydgregory@gmail.com> wrote:
>>>> On Fri, Aug 12, 2011 at 9:54 AM, sebb <sebbaz@gmail.com> wrote:
>>>>> On 12 August 2011 14:33, Gary Gregory <garydgregory@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 <scolebourne@joda.org>
wrote:
>>>>>>
>>>>>>> On 12 August 2011 11:19, sebb <sebbaz@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message