commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: [VFS] Analysis of binary compatibility breaks between 1.0 and 2.0; release strategy
Date Wed, 17 Nov 2010 17:32:54 GMT
On Wed, Nov 17, 2010 at 12:25 PM, Gary Gregory
<> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message