On Thu, Jun 2, 2016 at 1:22 PM, Benedikt Ritter <brit...@apache.org> wrote:
> 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. > Check. Do you want to RM? Or Sebb? Gary > > 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 > > > > > -- 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
