commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: [collections] Generifying Collections
Date Thu, 26 Oct 2006 19:20:04 GMT
On 10/26/06, Jörg Schaible <> wrote:
> Kris Nuttycombe wrote:
> > 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.
> I was just about to take the same example. Digester 1.7 also depends on
> older beanutils 1.6.1 or ancient JCL 1.0(.0)

Then the options are:

1) don't upgrade
2) yell at middle project to do a new release (ie: Digester in this case)
3) yell at us to do a backport release (ie: you need specific bugfixes
on the collections 2.x branch and not the 3.x one).
4) do it yourself and depend on an internal fork (of either 2 or 3).
5) risk that the library is backwards compatible for the necessary
features (by testing lots and hoping).

I still think that's a better world than package name changing every
time we want to make a non-backwards compatible change.

> > 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?
> Exaclty. And big commercial venders are even worse. If you do not use
> exactly their delivered dependency, you can lose the maintenance because
> you have an "undefined" environment.

Doesn't that mean you'd be kept off of Collections 4.x too?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message