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