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. >>> > 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-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
