Let's look at this from a different POV: 1) If we release 2.1 as is, we are creating a risk. We are strictly speaking breaking BC. 2) If we release trunk as 3.0 with a package and Maven coordinate change, then there is zero risk. If you want to use the new version, you MUST change your imports.
The risk, as remote as it may seem, is what I run into regularly dealing with a deep stack: I do not depend on jar Z but I depend on X, I compile against X. X depends on Y depends on Z. If there is BC problem in X, I can deal with it. If it is in Y or Z then I am due for some hacking. For example, here are two BC breaks in maintenance releases I recently found: - https://issues.apache.org/jira/browse/WSS-577 Binary compatibility broken between version <=2.1.3 and >=2.1.4 with org.apache.wss4j.dom.WSSecurityEngineResult - https://issues.apache.org/jira/browse/SANTUARIO-440 Binary compatibility broken between version 2.0.5 and 2.0.4 in org.apache.xml.security.c14n.CanonicalizationException In these two cases, I was very lucky that I could change my source code to match the changes. But these changes should have never been made in a maintenance release. So... the least risky option is (2), which is a 0-risk option. Gary On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser <els...@apache.org> wrote: > Hah, thanks for the details, Ralph. I will be sure to bring myself up to > speed. > > That being said: I would still like to get some consensus from those who > will be voting from the PMC on what should be done, given the current > report (since my opinion and thus vote are non-binding :D) > > http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/ > > > Ralph Goers wrote: > >> 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 >>> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
