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 13:33:11 GMT
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?
- if not, which is my current view, then package is codec2

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 ;)

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.

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


Mime
View raw message