commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Nuttycombe <Kris.Nuttyco...@noaa.gov>
Subject Re: [collections] Generifying Collections
Date Thu, 26 Oct 2006 16:54:07 GMT
Henri Yandell wrote:
> I've mulled it for a bit, and I don't think that it's worth it for us
> to try and change package names to make it easier for people not to be
> held up by other entities. If we do that then there will be less
> pressure for those projects to upgrade, and we'll just be causing lots
> of pain for the many to save pain for a much smaller group. Admittedly
> the many get their pain at compile time while the smaller group
> wouldn't have found their pain until runtime if they don't have good
> build practices.
That's quite a hard line to take. A great many projects depend upon 
older versions of the commons jars, and getting the development group 
for a third-party jar that you depend upon to upgrade their dependencies 
can be a process that takes way too long for many development 
environments. Hell, this is a problem even within commons - I have an 
application that depends on Digester 1.7, which in turn depends upon 
Collections 2.1 while my code needs features from Collections 3.2, and 
the only reason it works is because 3.2 is backwards compatible for the 
features that Digester is using.

Realistically, users only have so much leverage on projects to get them 
to upgrade, and development teams only have so much time to cut new 
releases. Are we going to start doing point releases for our own 
projects for dependency version upgrades whenever someone requests it?
> So I'm -1 to the package stuff - just not convinced by the argument so
> far. I do hope that we can get the generics stuff moving without the
> package name bit being an issue until we release.
I'm definitely +1 to getting moving, so would folks agree to at least 
create a branch from the head of collections where the development can 
get started? We can always move stuff around in SVN as needed at a later 
date.

Kris

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