Hello, I will/would vote for releasing 2.1 even when there are some minor problems (if it is well documented). Because I do see a large number of bugs for 2.0 and those users wont easily profit from a 3.0 (and I dont think backporting or removing of all incompatibilities will happen).
Having said that I do have a 2.0 provider which runs fine with 2.1 (source and binary). Maybe some of the clirr violations could be addressed to keep the changes strictly on the spi side. It should not stop us from also releasing a 3.0 shortly afterwards. (Personally I would however more work on the 2.x branch as I have the api packages in a product where i cannot ask customers to upgrade (but I can ask them to not use the incompat classes). Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Josh Elser <els...@apache.org> To: Commons Developers List <dev@commons.apache.org> Sent: Sa., 30 Apr. 2016 0:11 Subject: Re: [VFS] 2.1 clirr report 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
