FWIW, these discussions are not new. You might enjoy reading these threads - http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe not! ;-)
Ralph > On Apr 29, 2016, at 12:43 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> >> On Apr 29, 2016, at 10:57 AM, Josh Elser <els...@apache.org> wrote: >> >> >> >> 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 :) > > I would have to search the dev mailing list but this has been discussed in > the past. The first link below discusses the versioning policy but does not > explicitly call out changing the package name and artifactid. The second two > links are example of release announcements for incompatible releases. > > https://commons.apache.org/releases/versioning.html > <https://commons.apache.org/releases/versioning.html> > <https://commons.apache.org/releases/versioning.html > <https://commons.apache.org/releases/versioning.html>> > http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html > > <http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html> > > <http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html > > <http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html>> > https://commons.apache.org/proper/commons-collections/release_4_0.html > <https://commons.apache.org/proper/commons-collections/release_4_0.html> > <https://commons.apache.org/proper/commons-collections/release_4_0.html > <https://commons.apache.org/proper/commons-collections/release_4_0.html>> > > Ralph
