On 2 June 2016 at 11:20, Dave Brosius <dbros...@apache.org> wrote: > Commons should be happy to ignore compatibility, update to 1.8, change > package and maven coordinates, change interfaces to take advantage of > generics, become a modern code base. Staying in the 1.5 world, BCEL, which > is already dying, will die. No competent developer coming in from the > outside will look at BCEL and say, now _that_ is something i want to work > on. > > This was the plan all along, and then someone came along and said, why are > we breaking backwards compatibility, and undid everything. > > This is a major version, can we please move forward.
Fine, provided that there is consensus to do so. But I have yet to see agreement that breaking compatibility is acceptable. There are several people who value compatibility over modernity. Note that it would also be possible to release BCEL as two separate versions. One which maintains compatibility, and the other which starts again with a new design/package/coords. > > > > On 06/02/2016 06:07 AM, sebb wrote: >> >> No, it's a consequence of the way the Java classpath and Maven work. >> >> If Commons wishes to release a compatible version of BCEL, it must use >> the same Java package and Maven coordinates. >> (as well as ensure that any changes to the public API are at least >> binary-compatible) >> >> If Commons is happy to ignore compatibility, it can release a new >> version with different package and Maven coordinates. >> However this means downstream users have to update and recompile their >> source. >> >> >> >> On 2 June 2016 at 10:41, dbrosIus <dbros...@baybroadband.net> wrote: >>> >>> This is the problem with Commons. >>> >>> -------- Original message -------- >>> From: sebb <seb...@gmail.com> >>> Date: 06/02/2016 5:15 AM (GMT-05:00) >>> To: Commons Developers List <dev@commons.apache.org> >>> Subject: Re: [bcel] Deprecated InstructionConstants >>> >>> On 2 June 2016 at 07:56, Benedikt Ritter <brit...@apache.org> wrote: >>>> >>>> Gary Gregory <garydgreg...@gmail.com> schrieb am Do., 2. Juni 2016 um >>>> 08:00 Uhr: >>>> >>>>> So trunk packages would be renamed _back_ from bcel6 to the 5.2 >>>>> packages? >>>>> >>>> That's what I understood from sebb's last message. >>> >>> Yes, that would need to happen to support BC. >>> >>>>> Gary >>>>> >>>>> On Wed, Jun 1, 2016 at 3:43 PM, sebb <seb...@gmail.com> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> On 1 June 2016 at 09:34, Jan Matèrne (jhm) <apa...@materne.de> wrote: >>>>>>>> >>>>>>>> It does not make sense though. All of the code in the bcel6 package >>>>>>>> is >>>>>>>> going to be released for the first time in the upcoming 6.0 release. >>>>>>> >>>>>>> Ok, didnt know that. >>>>>>> Then I'm fine :) >>>>>>> >>>>>>> Just wanted to give a hint. >>>>>>> >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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 >>>>> >>> --------------------------------------------------------------------- >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
