I suspect Gary wants a 5.3 release because the CLIRR Maven plugin fails in Java 8 which has resulted in https://github.com/mojohaus/clirr-maven-plugin/issues/3 <https://github.com/mojohaus/clirr-maven-plugin/issues/3>, LANG-1025, and WICKET-5836 among others. We ran into this in Log4j, which I am pretty sure what got Gary motivated.
Ralph > On Jun 7, 2016, at 8:24 AM, Benedikt Ritter <brit...@apache.org> wrote: > > Hi, > > sebb <seb...@gmail.com> schrieb am Di., 7. Juni 2016 um 11:49 Uhr: > >> On 6 June 2016 at 21:02, Gary Gregory <garydgreg...@gmail.com> wrote: >>> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <brit...@apache.org> >> wrote: >>> >>>> Hi all, >>>> >>>> I had a brief look at the state of BCEL wrt doing a last 5.x release. >> Well, >>>> it feels like that is going to be a mess: >>>> >>>> - We have @since 6.0 annotations all over the code. >>>> - We have same deprecated classes - why if the code is currently in the >>>> shape for the 6.0 release, there should be no deprecated stuff >>>> - We have chances.xml which are talking about the next big 6.0 release. >>>> - We have renamed package coordinates which make it hard to generate a >>>> Clirr report. >>>> >>>> This will all have to be resolved before we can do the 5.3 release. I'm >>>> currently wondering what might be the best way to push out the 5.x >> release. >>>> I think we should create the 5.x branch ASAP, so that the way is free >> for >>>> work on the important stuff in trunk. Hopefully this will enable us to >>>> implement the missing bits for Java 8 support and get the 6.0 release >> out >>>> of the door soon. >>>> >>>> Thoughts? >>>> >>> >>> It seems like we are stuck in the middle b/w 6.0 and 5.3. >>> >>> How about letting bcel6 stand and finish 6.0? This makes Sebb's recent >> work >>> a bit of a waste but might make migrating from 5.2 easier anyway. >> >>> We can do the best we can for bcel6. We can do more clean ups and so on. >>> >>> Some users will migrate, others can be asked to provide patches to 5.2 >> for >>> a 5.3. >> >> -1 for several reasons. >> >> 0) I think we are fairly close to being able to release compatible >> code with all the necessary fixes >> >> 1) I don't believe we should force users to migrate their code in >> order to support java 7/8. >> In the case of Findbugs, this would also require all detector plugins to >> change. >> >> 2) the BCEL6 redesign has barely started. yes, some minor changes have >> been done to tidy the code, but nothing has been done to the original >> design, which is full of mutable classes and non-private mutable data. >> I think a lot more needs to be done to produce an API which will be >> sufficiently stable. >> Otherwise there will soon be another API break. >> > > I'm okay with the 5.3 release. But right know it feels like you're the only > one wants to go through the trouble. > > I propose we create the 5.x branch now. Those who want/need a compatible > release can work that out in that branch. All others can work on trunk to > get BCEL 6 out of the door with Java 7 and Java 8 compatibility. > > Benedikt > > >> >>> Then we can gather patches for a 100% BC 5.3. If 5.2 users care that much >>> for 5.2 instead of migrating, I would help that they would be ready to >> step >>> in with patches. >> >>> Gary >>> >>> >>>> Benedikt >>>> >>> >>> >>> >>> -- >>> 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 >> >>
