commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@scalaris.com>
Subject Re: [VFS] Analysis of binary compatibility breaks between 1.0 and 2.0; release strategy
Date Wed, 17 Nov 2010 17:46:16 GMT
James Carman wrote:

> On Wed, Nov 17, 2010 at 12:25 PM, Gary Gregory
> <GGregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message