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<els...@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<els...@apache.org> wrote:
Hah, thanks for the details, Ralph. I will be sure to bring myself
up to
speed.
That being said: I would still like to get some consensus from
those who
will be voting from the PMC on what should be done, given the current
report (since my opinion and thus vote are non-binding :D)
http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
Ralph Goers wrote:
FWIW, these discussions are not new. You might enjoy reading these
threads -
http://www.mail-archive.com/user@commons.apache.org/msg03711.html.
But
maybe not! ;-)
Ralph
On Apr 29, 2016, at 12:43 PM, Ralph Goers<ralph.go...@dslextreme.com>
wrote:
On Apr 29, 2016, at 10:57 AM, Josh Elser<els...@apache.org> wrote:
Ralph Goers wrote:
On Apr 29, 2016, at 9:27 AM, Josh Elser<els...@apache.org> wrote:
sebb wrote:
On 29 April 2016 at 16:19, Josh Elser<els...@apache.org> wrote:
sebb wrote:
On 29 April 2016 at 15:59, Josh Elser<els...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
