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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
