Okay, so were are we now? - people are waiting for a new release - package coords have changed - BC is broken - sebb has put effort into making all changes compatible - two interface changes remain
Is that correct? Then let's just get over with this two interfaces mach make the API redesign afterwards. Let's create two extension interfaces release this stuff with the old package and maven coord and we're done. sebb <seb...@gmail.com> schrieb am Do., 2. Juni 2016 um 14:19 Uhr: > On 2 June 2016 at 12:35, Jörg Schaible <joerg.schai...@bpm-inspire.com> > wrote: > > Hi, > > > > sebb wrote: > > > >> Hang on please. > >> > >> There were plans to produce a new incompatible release with new Maven > >> coords and new package names. > >> However as I recall there was some pushback from users who wished to > >> have a drop-in release. > >> That is not possible unless the release is binary compatible. > > > > The question is, why does one want to have a BC release? If Oliver uses > it > > as drop-in replacement, he will not use any new stuff, i.e. he might be > > interested to get simply a version working with Java 8 runtime. > > > >> So I spent quite a bit of effort reworking the changes so as to > >> facilitate a binary compatible release. > >> As far as I can recall, that effort was successful apart from changes > >> to an interface (or two). > >> > >> There were some ideas as to how to resolve the interface > >> incompatibilty, but no agreement was reached. > >> I think the options were: > >> - introduce new interface(s) extending the old one(s) > >> - keep the interface(s) and handle any runtime errors > >> - use the Java 8 (?) facility which allows an interface to contain a > >> method implementation. > >> > >> Note that the code does not yet support some Java 8 features. > > > > I'd really go on with bcel6 and new GAV using Java 8 as minimum and > backport > > anything to 5.x that is required to let BCEL run on Java 8 runtime, but > > nothing else. > > > > I am normally also in the BC camp, but I realize that we stress it > sometimes > > too much and actually harm further development of a component. After > several > > years of (public) inactivity of a component, we should really take the > > advantage for a cut. > > > > The effort to release an additional 5.x after a major 6.0 is negligible > > Not sure I agree the effort is negligible. > > > compared to the constant annoyance by the limits of ancient JDKs working > on > > the interesting stuff for a component. > > The JDK required to run BCEL is orthogonal to compatibility. > > Indeed there was a proposal to use Java 8 default interface methods to > get round the issue with compatibility. > > Please let's not conflate the two issues. > > > Cheers, > > Jörg > > > > > > --------------------------------------------------------------------- > > 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 > >
