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 :)
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
