commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [codec] getting the bmpm code out there
Date Fri, 12 Aug 2011 13:54:00 GMT
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?

> - 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.

> 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


Mime
View raw message