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/04/29 05:50:33 UTC
[VFS] 2.1 clirr report
It looks like there are about 7 areas in core/ where compatibility
against 2.0 has been broken:
* Methods added to o.a.c.v.{FileContent,FileName,FileObject}
* Method added to o.a.c.v.RandomAccessContent
* Parameters changed on method(s) in
o.a.c.v.p.{b.Bzip2FileObject,g.GzipFileObject}
* Changes from TarEntry to TarArchiveEntry
* Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider
Where do you define what are acceptable changes in a release? Is this
going to be a sticking-point?
http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
- Josh
---------------------------------------------------------------------
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
Re: [VFS] 2.1 clirr report
Posted by Josh Elser <el...@apache.org>.
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 sebb <se...@gmail.com>.
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
Re: [VFS] 2.1 clirr report
Posted by Josh Elser <el...@apache.org>.
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
Re: [VFS] 2.1 clirr report
Posted by Gary Gregory <ga...@gmail.com>.
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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VFS] 2.1 clirr report
Posted by ec...@zusammenkunft.net.
Hello,
I will/would vote for releasing 2.1 even when there are some minor problems (if it is well documented). Because I do see a large number of bugs for 2.0 and those users wont easily profit from a 3.0 (and I dont think backporting or removing of all incompatibilities will happen).
Having said that I do have a 2.0 provider which runs fine with 2.1 (source and binary).
Maybe some of the clirr violations could be addressed to keep the changes strictly on the spi side.
It should not stop us from also releasing a 3.0 shortly afterwards. (Personally I would however more work on the 2.x branch as I have the api packages in a product where i cannot ask customers to upgrade (but I can ask them to not use the incompat classes).
Bernd
--
http://bernd.eckenfels.net
-----Original Message-----
From: Josh Elser <el...@apache.org>
To: Commons Developers List <de...@commons.apache.org>
Sent: Sa., 30 Apr. 2016 0:11
Subject: Re: [VFS] 2.1 clirr report
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
Re: [VFS] 2.1 clirr report
Posted by Josh Elser <el...@apache.org>.
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
Re: [VFS] 2.1 clirr report
Posted by Ralph Goers <ra...@dslextreme.com>.
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
Re: [VFS] 2.1 clirr report
Posted by Ralph Goers <ra...@dslextreme.com>.
> 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>
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>
Ralph
Re: [VFS] 2.1 clirr report
Posted by Josh Elser <el...@apache.org>.
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 :)
If it's not yet clear, I do not have any confusion about what source and
binary compatibility is. My confusion is around Commons' application of
"compatibility", specifically, my current understanding of what is done
for compatibility would make me unhappy as a user. However, that is a
completely separate discussion that can be had at a later time.
My goal here is to find out what the Commons PMC considers to be
blockers to a release so I can avoid wasting time in cutting RCs that
will just be immediately -1'ed. That's why I keep asking for
documentation on your policies :)
I still don't have a clear understanding of what *needs* to be done to
cut 2.1 which is why I keep poking at this all, trying to get an answer
by understanding your policies.
> What matters is what the expectation is as to how users are going to use VFS in their projects. Most will use the providers that we have created. Some may implement their own. We may say that most users can just drop in the jar but if you are doing a), b) and/or c) (whatever those are defined to be) that you must recompile your code.
Is this an indirect way of asking me as release manager to enumerate
this "matrix" for you then as a part of the release process or are you
just stating your view of how you would like it work?
---------------------------------------------------------------------
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 Ralph Goers <ra...@dslextreme.com>.
> 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.
What matters is what the expectation is as to how users are going to use VFS in their projects. Most will use the providers that we have created. Some may implement their own. We may say that most users can just drop in the jar but if you are doing a), b) and/or c) (whatever those are defined to be) that you must recompile your code.
Ralph
Re: [VFS] 2.1 clirr report
Posted by Josh Elser <el...@apache.org>.
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.
>>>>> Where do you all define what is public API (and thus what is stated to
>>>>> be
>>>>> stable)?
>>>>>
>>>
>>> That's the big question...
>>>
>> So, let me give some personal opinions here: you cannot claim to have any
>> level of compatibility if you do not prominently define what is subject to
>> compatibility. Just take a look at the introduction on semver[1]: "For this
>> system to work, you first need to declare a public API".
>>
>> It is my strong opinion that any attempt to "improve compatibility" is
>> pointless if you haven't actually put forth the effort to define what you're
>> keeping compatible.
>>
>> The feeling I'm getting is that this is not defined. As such, I feel this is
>> going the same way as the "we should upgrade min JDK" and "we should upgrade
>> dependencies" -- it's not ready to go and should be addressed in a future
>> release.
>>
>> I don't want to come across as dismissive, but I've had this conversation
>> with more than one other project in the past. If there are concerns, let's
>> state them, discuss how they be addressed, and move on so we can avoid
>> unclear worries.
>
> I agree that we are not very good at defining what is public API.
>
> Or rather, we are not very good at defining what is *not* intended to be public.
>
> This is a general problem with Java projects that have more than one
> level of package.
> Methods and fields often have to be made public or protected to
> satisfy internal use.
>
> So in the end it may come down to a judgement call as to which parts
> of the otherwise public API are unlikely to be used externally.
A common approach is to define artifacts or specifics packages in an
artifact which is guaranteed to be stable. Yes, as you say this is hard.
It sounds to me like compatibility is not something commons-vfs is
anywhere close to guaranteeing presently (as it's presently undefined)
and it should not hold up a release of 2.1 (my two cents).
---------------------------------------------------------------------
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 sebb <se...@gmail.com>.
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.
>>> > Where do you all define what is public API (and thus what is stated to
>>> > be
>>> > stable)?
>>> >
>>
>>
>> That's the big question...
>>
>
> So, let me give some personal opinions here: you cannot claim to have any
> level of compatibility if you do not prominently define what is subject to
> compatibility. Just take a look at the introduction on semver[1]: "For this
> system to work, you first need to declare a public API".
>
> It is my strong opinion that any attempt to "improve compatibility" is
> pointless if you haven't actually put forth the effort to define what you're
> keeping compatible.
>
> The feeling I'm getting is that this is not defined. As such, I feel this is
> going the same way as the "we should upgrade min JDK" and "we should upgrade
> dependencies" -- it's not ready to go and should be addressed in a future
> release.
>
> I don't want to come across as dismissive, but I've had this conversation
> with more than one other project in the past. If there are concerns, let's
> state them, discuss how they be addressed, and move on so we can avoid
> unclear worries.
I agree that we are not very good at defining what is public API.
Or rather, we are not very good at defining what is *not* intended to be public.
This is a general problem with Java projects that have more than one
level of package.
Methods and fields often have to be made public or protected to
satisfy internal use.
So in the end it may come down to a judgement call as to which parts
of the otherwise public API are unlikely to be used externally.
> [1] http://semver.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>.
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...
>> > Where do you all define what is public API (and thus what is stated to be
>> > stable)?
>> >
>
> That's the big question...
>
So, let me give some personal opinions here: you cannot claim to have
any level of compatibility if you do not prominently define what is
subject to compatibility. Just take a look at the introduction on
semver[1]: "For this system to work, you first need to declare a public
API".
It is my strong opinion that any attempt to "improve compatibility" is
pointless if you haven't actually put forth the effort to define what
you're keeping compatible.
The feeling I'm getting is that this is not defined. As such, I feel
this is going the same way as the "we should upgrade min JDK" and "we
should upgrade dependencies" -- it's not ready to go and should be
addressed in a future release.
I don't want to come across as dismissive, but I've had this
conversation with more than one other project in the past. If there are
concerns, let's state them, discuss how they be addressed, and move on
so we can avoid unclear worries.
[1] http://semver.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 sebb <se...@gmail.com>.
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.
> Where do you all define what is public API (and thus what is stated to be
> stable)?
>
That's the big question...
> Gary Gregory wrote:
>>
>> We have 2 choices IMO: document breaks or change package name. The later
>> is
>> safer from a jar hell POV.
>>
>> The question is how likely are the changes going to break BC IRL? There
>> are
>> two main use cases: user like call sites and implementors of providers.
>>
>> Thoughts?
>>
>> Gary
>> It looks like there are about 7 areas in core/ where compatibility against
>> 2.0 has been broken:
>>
>> * Methods added to o.a.c.v.{FileContent,FileName,FileObject}
>> * Method added to o.a.c.v.RandomAccessContent
>> * Parameters changed on method(s) in
>> o.a.c.v.p.{b.Bzip2FileObject,g.GzipFileObject}
>> * Changes from TarEntry to TarArchiveEntry
>> * Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider
>>
>> Where do you define what are acceptable changes in a release? Is this
>> going
>> to be a sticking-point?
>>
>> http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
>>
>> - Josh
>>
>> ---------------------------------------------------------------------
>> 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>.
How does changing the package name help? Doesn't that just push a
NoClassDefFound error instead of some missing implementation for a new
method?
Where do you all define what is public API (and thus what is stated to
be stable)?
Gary Gregory wrote:
> We have 2 choices IMO: document breaks or change package name. The later is
> safer from a jar hell POV.
>
> The question is how likely are the changes going to break BC IRL? There are
> two main use cases: user like call sites and implementors of providers.
>
> Thoughts?
>
> Gary
> It looks like there are about 7 areas in core/ where compatibility against
> 2.0 has been broken:
>
> * Methods added to o.a.c.v.{FileContent,FileName,FileObject}
> * Method added to o.a.c.v.RandomAccessContent
> * Parameters changed on method(s) in
> o.a.c.v.p.{b.Bzip2FileObject,g.GzipFileObject}
> * Changes from TarEntry to TarArchiveEntry
> * Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider
>
> Where do you define what are acceptable changes in a release? Is this going
> to be a sticking-point?
>
> http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
>
> - Josh
>
> ---------------------------------------------------------------------
> 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 Gary Gregory <ga...@gmail.com>.
We have 2 choices IMO: document breaks or change package name. The later is
safer from a jar hell POV.
The question is how likely are the changes going to break BC IRL? There are
two main use cases: user like call sites and implementors of providers.
Thoughts?
Gary
It looks like there are about 7 areas in core/ where compatibility against
2.0 has been broken:
* Methods added to o.a.c.v.{FileContent,FileName,FileObject}
* Method added to o.a.c.v.RandomAccessContent
* Parameters changed on method(s) in
o.a.c.v.p.{b.Bzip2FileObject,g.GzipFileObject}
* Changes from TarEntry to TarArchiveEntry
* Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider
Where do you define what are acceptable changes in a release? Is this going
to be a sticking-point?
http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
- Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org