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