Torsten Curdt wrote:
On 10/25/06, James Carman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
