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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
