commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [BCEL] 5.3 is going to be messy
Date Tue, 07 Jun 2016 15:24:38 GMT
Hi,

sebb <sebbaz@gmail.com> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:

> On 6 June 2016 at 21:02, Gary Gregory <garydgregory@gmail.com> wrote:
> > On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <britter@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message