On 10/26/06, Jörg Schaible <[EMAIL PROTECTED]> 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?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
