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