> 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.)
Sorry, not sure I get what you are saying If it's just your decision to upgrade a library you should not be moaning about work. We are talking about a major API change! Don't expect that to be done with a jar replacement. If you have to upgrade because another library is depending on another version that's another story ...and then comes the question whether that's easy or not.
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.
Your project depends on A and B. A depends on the old-style collections while B already made the move and uses the new collections. Now what? As it is an incompatible change the only thing is trying to push A to upgrade its dependency. (or jarjar magic) THAT is what I call a PITA. While otherwise they would be happily living next to each other and everyone is happy. For sure we could provide some scripts or even eclipse refactoring scripts if necessary/possible. Most likely you will only need to remove all imports and ask eclipse to organize imports on your code base anyway. To me that sounds easier than trying to squeeze (let's face it) a new API into the same package. cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
