commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <willp...@sourcelabs.com>
Subject Re: [collections] Generifying Collections
Date Thu, 26 Oct 2006 16:58:05 GMT
Torsten Curdt wrote:
> On 10/25/06, James Carman <james@carmanconsulting.com> wrote:
>> For someone who uses Commons Collections a lot in their applications, 
>> this
>> is going to be quite a pain if I want to upgrade.  Yes, I realize that
>> there's such a thing as find and replace, but the fact that I have to do
>> that if I want to upgrade is just a bother.  That's my $0.02.
>
> Well, easy ...then you don't upgrade ;)
>
> Sorry, but the fact that an upgrade is not always is as easy as
> replacing a jar is not an argument (IMO) As long as there is an
> upgrade path it's up to the user to walk that path or not. The
> important thing though is to have such a path.
This seems like a strange argument, since the "Don't Upgrade" path is 
valid for people who are running into conflicts from API changes as well 
(and there are probably a lot more people that won't run into these 
problems if the removals are mostly focused on deprecated components.)

I understand that sometimes conflicts can be a bit round about, they 
upgrade to (or add) a new component of Y and it causes their 
commons-collections to get upgraded.  They still have the choice of not 
making this upgrade, or using that other component.  Or they have the 
choice of using JarJar or some other tool force package changes.  Or 
helping to fix the dependency if they are using some open source project.

I think we want to make the common case as easy as possible, and 
changing the package names makes the common case a pain in the butt.

I would suggest this means staying as close to backwards compatible as 
possible, with the removal of only things that have been deprecated.
> cheers
> -- 
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message