You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Josh Elser <el...@apache.org> on 2016/05/01 21:27:22 UTC
Re: [VFS] 2.1 clirr report
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<el...@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<el...@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<ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Apr 29, 2016, at 10:57 AM, Josh Elser<el...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Ralph Goers wrote:
>>>>>>>
>>>>>>>> On Apr 29, 2016, at 9:27 AM, Josh Elser<el...@apache.org> wrote:
>>>>>>>>> sebb wrote:
>>>>>>>>>
>>>>>>>>>> On 29 April 2016 at 16:19, Josh Elser<el...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> sebb wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 29 April 2016 at 15:59, Josh Elser<el...@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
Re: [VFS] 2.1 clirr report
Posted by Josh Elser <el...@apache.org>.
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<el...@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<el...@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<ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Apr 29, 2016, at 10:57 AM, Josh Elser<el...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Ralph Goers wrote:
>>>>>>>>
>>>>>>>>> On Apr 29, 2016, at 9:27 AM, Josh Elser<el...@apache.org> wrote:
>>>>>>>>>> sebb wrote:
>>>>>>>>>>
>>>>>>>>>>> On 29 April 2016 at 16:19, Josh Elser<el...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> sebb wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 29 April 2016 at 15:59, Josh Elser<el...@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