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:40:07 GMT
Also, looks like I'm wrong about the static member moving up to a parent 
class (WebdavFileProvider to HttpFileProvider). I thought this wouldn't 
work, but a quick experiment shows that it's fine.

Josh Elser wrote:
> 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