-1.The commons-collections site states that: "Of course, backwards compatibility has been retained during all transitions using deprecation." Is that statement not true?
The commons-collections folks screwed much of the world (although not us,
because we only depend on a couple of classes that weren't moved to new
packages without backwards compatible deprecations) with their recent backwards
incompatible changes. I'm not interested in supporting that behavior by
continuing to depend on them.
Craig, you're listed as a commiter on the commons-collections site (http://jakarta.apache.org/commons/collections/team-list.html). At the same time, I saw a post from you regarding a collections vote saying that your vote was "Enthusiastic (but non-binding) +1 from a non-committer. " (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=35499). I assume that you're not a commons-collections commiter, but thought you might want to clarify for others out there who may not have found the post and are asking themselves why you, as a commiter, didn't veto the changes.Put yourself in the position of a sysadmin for a Tomcat 5 installation where some webapps need the old version of commons-collections.jar and some need the new version. What are *you* going to do?
Anyhow. . .
It seems like instead of shying away from dependencies (especially apache ones) the appropriate course of action should be to adopt a guideline for commons projects to ensure that in the future ALL releases are backwards compatible . I mean, what good is a commons project if it's releases aren't used on other projects out of the fear of incompatibility?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
