James Carman wrote: > On Wed, Nov 17, 2010 at 12:25 PM, Gary Gregory > <ggreg...@seagullsoftware.com> wrote: >>> My feeling is that if we are upgrading to Java 5 then we should do it >>> correctly. Go ahead and break compatibility where required. In that view >>> the changes done to the Comparables were done correctly. I suspect they >>> will cause very few problems in any case. Since we have changed the >>> package name and artifactId I just wouldn't worry about it. >>> >>> I agree we should remove the deprecated APIs - there don't appear to be >>> many of them - although I do find myself wondering why in >>> AbstractFileObject doSetLastModifiedTime was deprecated in favor of >>> doSetLastModTime. I actually prefer the former name. >> >> +1 >> > > +1. I say keep things the way they are now. It's not just about > client libraries having to fix themselves. It's mostly about client > libraries using other libraries that could rely on a binary > incompatible version of VFS. Of course it's no trouble (or at least > not much) to fix my code to use the new API. However, suppose I rely > on Library X which uses an older, incompatible version of VFS? What > do I do then if the package names haven't changed? Bottom line, if > you're breaking compatibility in any way, you need to bump the major > version number. With that comes the package and artifactId change, as > suggested.
+1 :) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
