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 > >
