On 30 August 2017 at 20:11, Benedikt Ritter <brit...@apache.org> wrote: > Hi, > > looking through the JavaDoc comments in the Visitor interface, it looks like > we added additional methods in the 6.0 release. 6.0 was a major release but > without package and maven coords change. Seems like we accepted this kind of > changes for 6.0. I’m not sure what point I’m trying to make here… But the > whole versioning/api evolution thingy looks pretty messy in BCEL.
A major version bump does not require changes to package names/maven coords. It just means that there have been major changes. However changing package/maven coords is a major change and so requires a major version bump. AFAIK 6.0 was binary compatible with the previous release. That was certainly the intention. > Cheers, > Benedikt > >> Am 30.08.2017 um 16:37 schrieb Gary Gregory <garydgreg...@gmail.com>: >> >> We recently dealt with this kind of compatibility issue in Log4j 2 and we >> decided to subclass the interface in question. I suggest we do the same >> here. Not pretty but it is type safe and bullet-proof. >> >> Gary >> >> On Tue, Aug 29, 2017 at 5:17 AM, sebb <seb...@gmail.com> wrote: >> >>> On 28 August 2017 at 20:07, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> The question is whether this breaks binary compatibility. If it does, >>> this >>>> needs fixing. Unless there are other important changes that warrant a >>> major >>>> version, I would go the sub-interface route; ugly, but workable within >>> the >>>> same major release. >>> >>> According to [1], it seems it does not. >>> >>> However it will break source compatibility if a 3rd party implements >>> the interface. >>> >>> Also I seem to remember there were some concerns about the downstream >>> effect for 3rd party visitor implementations. >>> >>> IIRC it was that BCEL will expect to be able to invoke the new >>> methods; this will fail. >>> There may be ways around this by catching the exception. >>> >>> The dev list should have the details. >>> >>> [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html >>> >>>> Gary >>>> >>>> On Mon, Aug 28, 2017 at 12:58 PM, Benedikt Ritter <brit...@apache.org> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Rev. 1782852 [1] has introduced two breaking changes by adding the >>> methods: >>>>> >>>>> public void visitAnnotation(org.apache.bcel.classfile.Annotations) >>>>> public void visitAnnotationDefault(org.apache.bcel.classfile. >>>>> AnnotationDefault) >>>>> >>>>> to the interface org.apache.bcel.classfile.Visitor. The commit comment >>>>> indicates that these changes are needed by the Tomcat project. How do we >>>>> want to deal with this for the upcoming 6.1 release? I see several >>> options: >>>>> >>>>> - accept these changes and make it explicit in release notes >>>>> - add a new interface which extends from the Visitor interface and add >>> the >>>>> new methods to that interface >>>>> - major version bump (probably not the best idea…) >>>>> >>>>> Thoughts? >>>>> Benedikt >>>>> >>>>> [1] http://svn.apache.org/viewvc?view=revision&revision=1782852 < >>>>> http://svn.apache.org/viewvc?view=revision&revision=1782852> >>> >>> --------------------------------------------------------------------- >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
