commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [VFS] 2.1 clirr report
Date Sun, 01 May 2016 19:27:22 GMT
https://issues.apache.org/jira/browse/VFS-377 is the biggest 
not-easily-fixed change that breaks binary compatibility for 2.1 against 
2.0. The bzip/gzip file object changes are easily restored, as is a 
moved static member (I don't believe this is something that would

I can commit these changes, and, IMO, calling out VFS-377 as 
"intentionally changed" is fine.
work).

Bernd -- I think this also helps out the changes you suggested making.

But again, I'd *really* like to get consensus from the PMC. I'm stuck on 
making an RC until you all can agree what should be done :). I'll be 
committing the changes to (mostly) restore binary compat shortly.

sebb wrote:
> Has anyone looked at whether the changes really do affect BC?
> Note that the Maven Clirr does not distinguish between source compat and BC.
> Breaking source compat is not as serious an issue.
>
> For example, the new methds in various interfaces don't affect BC:
>
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100
>
> Some of the changes clearly do affect BC, but has anyone looked at
> whether the old API can be implemented in terms of the new?
>
> It may be a bit tedious to check, but if BC can be achieved then it
> reduces the downstream effort needed.
>
>
> On 30 April 2016 at 00:00, Josh Elser<elserj@apache.org>  wrote:
>> So, just call 2.1 instead 3.0? Fine by me.
>>
>> Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of)
>> commons-vfs3? Please confirm, Gary.
>>
>> I don't think we need to expound any more about why compatibility is
>> important. No one has even presented any such argument. Let's stick to
>> action :)
>>
>>
>> Gary Gregory wrote:
>>> Let's look at this from a different POV:
>>>
>>> 1) If we release 2.1 as is, we are creating a risk. We are strictly
>>> speaking breaking BC.
>>> 2) If we release trunk as 3.0 with a package and Maven coordinate change,
>>> then there is zero risk. If you want to use the new version, you MUST
>>> change your imports.
>>>
>>> The risk, as remote as it may seem, is what I run into regularly dealing
>>> with a deep stack: I do not depend on jar Z but I depend on X, I compile
>>> against X. X depends on Y depends on Z. If there is BC problem in X, I can
>>> deal with it. If it is in Y or Z then I am due for some hacking.
>>>
>>> For example, here are two BC breaks in maintenance releases I recently
>>> found:
>>>
>>> - https://issues.apache.org/jira/browse/WSS-577 Binary compatibility
>>> broken
>>> between version<=2.1.3 and>=2.1.4 with
>>> org.apache.wss4j.dom.WSSecurityEngineResult
>>> - https://issues.apache.org/jira/browse/SANTUARIO-440 Binary compatibility
>>> broken between version 2.0.5 and 2.0.4 in
>>> org.apache.xml.security.c14n.CanonicalizationException
>>>
>>> In these two cases, I was very lucky that I could change my source code to
>>> match the changes. But these changes should have never been made in a
>>> maintenance release.
>>>
>>> So... the least risky option is (2), which is a 0-risk option.
>>>
>>> Gary
>>>
>>> On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser<elserj@apache.org>   wrote:
>>>
>>>> Hah, thanks for the details, Ralph. I will be sure to bring myself up to
>>>> speed.
>>>>
>>>> That being said: I would still like to get some consensus from those who
>>>> will be voting from the PMC on what should be done, given the current
>>>> report (since my opinion and thus vote are non-binding :D)
>>>>
>>>> http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
>>>>
>>>>
>>>> Ralph Goers wrote:
>>>>
>>>>> FWIW, these discussions are not new.  You might enjoy reading these
>>>>> threads -
>>>>> http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But
>>>>> maybe not! ;-)
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Apr 29, 2016, at 12:43 PM, Ralph Goers<ralph.goers@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Apr 29, 2016, at 10:57 AM, Josh Elser<elserj@apache.org>
   wrote:
>>>>>>>
>>>>>>>
>>>>>>> Ralph Goers wrote:
>>>>>>>
>>>>>>>> On Apr 29, 2016, at 9:27 AM, Josh Elser<elserj@apache.org>
    wrote:
>>>>>>>>> sebb wrote:
>>>>>>>>>
>>>>>>>>>> On 29 April 2016 at 16:19, Josh Elser<elserj@apache.org>
     wrote:
>>>>>>>>>>
>>>>>>>>>>> sebb wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 29 April 2016 at 15:59, Josh Elser<elserj@apache.org>
>>>>>>>>>>>>    wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> How does changing the package name help?
Doesn't that just push
>>>>>>>>>>>>> a
>>>>>>>>>>>>>> NoClassDefFound error instead of
some missing implementation
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> a new
>>>>>>>>>>>>>> method?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That means we change ALL the package
names and the Maven coords.
>>>>>>>>>>>> Effectively it's a different component, and
users have to change
>>>>>>>>>>>> the
>>>>>>>>>>>> import package names.
>>>>>>>>>>>>
>>>>>>>>>>> How is that at all improving *any* level of compatibility?
I
>>>>>>>>>>> really
>>>>>>>>>>> don't
>>>>>>>>>>> see how that is providing any service to your
users. Now, instead
>>>>>>>>>>> of just
>>>>>>>>>>> updating the version for the artifact and adding
the new methods,
>>>>>>>>>>> they
>>>>>>>>>>> *also* have to change the package...
>>>>>>>>>>>
>>>>>>>>>> It's not about compatibility, it's about avoiding
jar hell.
>>>>>>>>>>
>>>>>>>>> Hold up now. We were talking about compatibility. I also
don't know
>>>>>>>>> specifically what you mean by "jar hell", but it sounds
like this is
>>>>>>>>> not
>>>>>>>>> relevant to the source/binary compatibility discussion
(and thus not
>>>>>>>>> relevant to this thread). Please correct me if I'm wrong.
>>>>>>>>>
>>>>>>>> If a user of VFS drops in the new jar in place of the old
one and
>>>>>>>> their application gets runtime errors then, by definition,
binary
>>>>>>>> compatibility is broken.  This can happen if the user implemented
>>>>>>>> their own
>>>>>>>> FileSystem and are using interfaces that have had new methods
added.
>>>>>>>> It can
>>>>>>>> happen if public methods have had signatures change.  If
any of these
>>>>>>>> happen then Commons policy is that the package names must
change and
>>>>>>>> the
>>>>>>>> artifact id must change, as the jar is no longer compatible
with the
>>>>>>>> old
>>>>>>>> one.  This allows the old jar and the new jar to be used
>>>>>>>> side-by-side.
>>>>>>>>
>>>>>>> Ok. Can you point me at this documentation? Apparently the issues
I
>>>>>>> take with this are more engrained into all of Commons :)
>>>>>>>
>>>>>> I would have to search the dev mailing list but this has been discussed
>>>>>> in the past.  The first link below discusses the versioning policy
but
>>>>>> does
>>>>>> not explicitly call out changing the package name and artifactid.
The
>>>>>> second two links are example of release announcements for incompatible
>>>>>> releases.
>>>>>>
>>>>>> https://commons.apache.org/releases/versioning.html<
>>>>>> https://commons.apache.org/releases/versioning.html>    <
>>>>>> https://commons.apache.org/releases/versioning.html<
>>>>>> https://commons.apache.org/releases/versioning.html>>
>>>>>>
>>>>>>
>>>>>> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
>>>>>> <
>>>>>>
>>>>>> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html>
>>>>>> <
>>>>>>
>>>>>> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
>>>>>> <
>>>>>>
>>>>>> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
>>>>>> https://commons.apache.org/proper/commons-collections/release_4_0.html<
>>>>>> https://commons.apache.org/proper/commons-collections/release_4_0.html>
>>>>>>
>>>>>> <https://commons.apache.org/proper/commons-collections/release_4_0.html<
>>>>>>
>>>>>> https://commons.apache.org/proper/commons-collections/release_4_0.html>>
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message