You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2016/06/06 19:44:21 UTC
[BCEL] 5.3 is going to be messy
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?
Benedikt
Re: [BCEL] 5.3 is going to be messy
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jun 6, 2016 at 1:02 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <br...@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.
>
> 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.
>
Fat fingers! "I would help that they would be ready to step in with
patches." -> "I would _hope_ that they would be ready to step in with
patches."
G
>
> 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
>
--
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
Re: [BCEL] 5.3 is going to be messy
Posted by James Carman <ja...@carmanconsulting.com>.
+1 Torsten
On Tue, Jun 7, 2016 at 6:17 AM Torsten Curdt <tc...@vafer.org> wrote:
> >
> > 1) I don't believe we should force users to migrate their code in
> > order to support java 7/8.
> >
>
> ...and that line of thinking is why it feels like commons projects are
> effectively stuck in the past.
>
> No one needs to upgrade. If your projects live in the past - there are bug
> fix releases.
> But if you want the new shiny then you as well should be OK to put in some
> effort to do so.
> Change should be easy - not just for our user but also for us.
>
> My 2 cents
>
Re: [BCEL] 5.3 is going to be messy
Posted by sebb <se...@gmail.com>.
On 7 June 2016 at 14:29, Dave Brosius <db...@apache.org> wrote:
>
>
> On 06/07/2016 06:39 AM, sebb wrote:
>>
>> On 7 June 2016 at 11:15, Torsten Curdt <tc...@vafer.org> wrote:
>>>>
>>>> 1) I don't believe we should force users to migrate their code in
>>>> order to support java 7/8.
>>>>
>>> ...and that line of thinking is why it feels like commons projects are
>>> effectively stuck in the past.
>>
>> And maybe the ease of upgrade is why they are popular with users.
>
>
> What upgrade? When have the users had to upgrade? like 3 years ago?
>>
>>
>>> No one needs to upgrade. If your projects live in the past - there are
>>> bug
>>> fix releases.
>>
>> That's not the case in general. Very few commons projects maintain
>> parallel releases.
>>
>>> But if you want the new shiny then you as well should be OK to put in
>>> some
>>> effort to do so.
>>
>> Why should the user have to do so?
>
>
> There's one thing above all else that really is painful to the user. No
> upgrades!
> Why are there no upgrades? Because there are no developers!
> Why are there no developers? Because they are punished with a horrendous
> development experience. Oh boy, can't wait to develop with 1.5 in SVN!!
> that's a treat.
You are conflating several issues in one.
The Java version is orthogonal to compatibility.
The source code implementation is nothing to do with either the Java
version or compatibility.
>>
>>> Change should be easy - not just for our user but also for us.
>>
>> There are many more users than there are developers.
>>
>>> My 2 cents
>>
>> Suppose there are 10 developers on BCEL; that's 20 cents.
>>
>> There may be 1000 or more users.
>>
>> That's 20 dollars.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Dave Brosius <db...@apache.org>.
On 06/07/2016 06:39 AM, sebb wrote:
> On 7 June 2016 at 11:15, Torsten Curdt <tc...@vafer.org> wrote:
>>> 1) I don't believe we should force users to migrate their code in
>>> order to support java 7/8.
>>>
>> ...and that line of thinking is why it feels like commons projects are
>> effectively stuck in the past.
> And maybe the ease of upgrade is why they are popular with users.
What upgrade? When have the users had to upgrade? like 3 years ago?
>
>> No one needs to upgrade. If your projects live in the past - there are bug
>> fix releases.
> That's not the case in general. Very few commons projects maintain
> parallel releases.
>
>> But if you want the new shiny then you as well should be OK to put in some
>> effort to do so.
> Why should the user have to do so?
There's one thing above all else that really is painful to the user. No
upgrades!
Why are there no upgrades? Because there are no developers!
Why are there no developers? Because they are punished with a horrendous
development experience. Oh boy, can't wait to develop with 1.5 in SVN!!
that's a treat.
>
>> Change should be easy - not just for our user but also for us.
> There are many more users than there are developers.
>
>> My 2 cents
> Suppose there are 10 developers on BCEL; that's 20 cents.
>
> There may be 1000 or more users.
>
> That's 20 dollars.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 7 Jun 2016 11:39:09 +0100, sebb wrote:
> On 7 June 2016 at 11:15, Torsten Curdt <tc...@vafer.org> wrote:
>>>
>>> 1) I don't believe we should force users to migrate their code in
>>> order to support java 7/8.
>>>
>>
>> ...and that line of thinking is why it feels like commons projects
>> are
>> effectively stuck in the past.
>
> And maybe the ease of upgrade is why they are popular with users.
>
>> No one needs to upgrade. If your projects live in the past - there
>> are bug
>> fix releases.
>
> That's not the case in general. Very few commons projects maintain
> parallel releases.
And why not?
Gilles
>
>> But if you want the new shiny then you as well should be OK to put
>> in some
>> effort to do so.
>
> Why should the user have to do so?
>
>> Change should be easy - not just for our user but also for us.
>
> There are many more users than there are developers.
>
>> My 2 cents
>
> Suppose there are 10 developers on BCEL; that's 20 cents.
>
> There may be 1000 or more users.
>
> That's 20 dollars.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Torsten Curdt <tc...@vafer.org>.
>
> > So? What's your point there?
>
> Commons libraries are generally very low level, and are often embedded
> deep within software stacks.
>
> So changes which require downstream changes are expensive when
> considered as a whole.
>
> This is very different from many other ASF projects which can
> generally be updated independently because there are no dependencies
> on them.
>
> My view is that we must not ignore the effect of Commons changes on
> the entire ecosystem.
>
Understood - but maybe we should also not overstate its role.
If we release something it does not automatically get applied to all those
software stacks. Only once people decide to upgrade will it end up in those
stacks.
And if people upgrade from foo 1.x to 2.x and expect everything to just
work then those are not the people we should take into consideration for
this discussion.
cheers,
Torsten
Re: [BCEL] 5.3 is going to be messy
Posted by sebb <se...@gmail.com>.
On 8 June 2016 at 00:56, Torsten Curdt <tc...@vafer.org> wrote:
>>
>> >> 1) I don't believe we should force users to migrate their code in
>> >> order to support java 7/8.
>> >>
>> >
>> > ...and that line of thinking is why it feels like commons projects are
>> > effectively stuck in the past.
>>
>> And maybe the ease of upgrade is why they are popular with users.
>>
>
> Well, let's call that a theory.
>
>
>
>> > No one needs to upgrade. If your projects live in the past - there are
>> bug
>> > fix releases.
>>
>> That's not the case in general. Very few commons projects maintain
>> parallel releases.
>>
>
> Not something we couldn't change - but I was thinking larger scale.
> It's a common pattern elsewhere.
>
>
>> But if you want the new shiny then you as well should be OK to put in some
>> > effort to do so.
>>
>> Why should the user have to do so?
>>
>
> Because it's not everyone's vision is to work so others don't even have to
> lift a finger to gain the benefits.
> We are volunteers! Idealism aside: I think there is a line - maybe people
> draw them differently.
> Especially if we want to attract or welcome new developers we need to find
> a balance.
>
> As user or dev: You want the new shiny, you don't have to pay for it - the
> least you can do is to make some minor code adjustments. I'd call it
> a courtesy. And that's how it works for many other open source projects,
> too.
> Right now I don't see commons "stability" as a blessing - rather a curse.
>
> Release early, release often.
> If your API doesn't change with every release - people will probably
> forgive you ...and love you for supporting the latest and greatest.
>
>
>> Change should be easy - not just for our user but also for us.
>>
>> There are many more users than there are developers.
>>
>
> So? What's your point there?
>
Commons libraries are generally very low level, and are often embedded
deep within software stacks.
So changes which require downstream changes are expensive when
considered as a whole.
This is very different from many other ASF projects which can
generally be updated independently because there are no dependencies
on them.
My view is that we must not ignore the effect of Commons changes on
the entire ecosystem.
>> My 2 cents
>>
>> Suppose there are 10 developers on BCEL; that's 20 cents.
>>
>> There may be 1000 or more users.
>>
>> That's 20 dollars.
>>
>
> 20 dollars no one of us will ever see. Have those 1000 user spend a dollar
> or two and maybe it will cover the cost of just this thread. I don't think
> that calculation will get us very far.
>
> cheers,
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Torsten Curdt <tc...@vafer.org>.
>
> >> 1) I don't believe we should force users to migrate their code in
> >> order to support java 7/8.
> >>
> >
> > ...and that line of thinking is why it feels like commons projects are
> > effectively stuck in the past.
>
> And maybe the ease of upgrade is why they are popular with users.
>
Well, let's call that a theory.
> > No one needs to upgrade. If your projects live in the past - there are
> bug
> > fix releases.
>
> That's not the case in general. Very few commons projects maintain
> parallel releases.
>
Not something we couldn't change - but I was thinking larger scale.
It's a common pattern elsewhere.
> But if you want the new shiny then you as well should be OK to put in some
> > effort to do so.
>
> Why should the user have to do so?
>
Because it's not everyone's vision is to work so others don't even have to
lift a finger to gain the benefits.
We are volunteers! Idealism aside: I think there is a line - maybe people
draw them differently.
Especially if we want to attract or welcome new developers we need to find
a balance.
As user or dev: You want the new shiny, you don't have to pay for it - the
least you can do is to make some minor code adjustments. I'd call it
a courtesy. And that's how it works for many other open source projects,
too.
Right now I don't see commons "stability" as a blessing - rather a curse.
Release early, release often.
If your API doesn't change with every release - people will probably
forgive you ...and love you for supporting the latest and greatest.
> Change should be easy - not just for our user but also for us.
>
> There are many more users than there are developers.
>
So? What's your point there?
> My 2 cents
>
> Suppose there are 10 developers on BCEL; that's 20 cents.
>
> There may be 1000 or more users.
>
> That's 20 dollars.
>
20 dollars no one of us will ever see. Have those 1000 user spend a dollar
or two and maybe it will cover the cost of just this thread. I don't think
that calculation will get us very far.
cheers,
Torsten
Re: [BCEL] 5.3 is going to be messy
Posted by sebb <se...@gmail.com>.
On 7 June 2016 at 11:15, Torsten Curdt <tc...@vafer.org> wrote:
>>
>> 1) I don't believe we should force users to migrate their code in
>> order to support java 7/8.
>>
>
> ...and that line of thinking is why it feels like commons projects are
> effectively stuck in the past.
And maybe the ease of upgrade is why they are popular with users.
> No one needs to upgrade. If your projects live in the past - there are bug
> fix releases.
That's not the case in general. Very few commons projects maintain
parallel releases.
> But if you want the new shiny then you as well should be OK to put in some
> effort to do so.
Why should the user have to do so?
> Change should be easy - not just for our user but also for us.
There are many more users than there are developers.
> My 2 cents
Suppose there are 10 developers on BCEL; that's 20 cents.
There may be 1000 or more users.
That's 20 dollars.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Gary Gregory <ga...@gmail.com>.
On Jun 7, 2016 3:17 AM, "Torsten Curdt" <tc...@vafer.org> wrote:
>
> >
> > 1) I don't believe we should force users to migrate their code in
> > order to support java 7/8.
> >
>
> ...and that line of thinking is why it feels like commons projects are
> effectively stuck in the past.
+1!
>
> No one needs to upgrade.
+1!!
If your projects live in the past - there are bug
> fix releases.
> But if you want the new shiny then you as well should be OK to put in some
> effort to do so.
> Change should be easy - not just for our user but also for us.
+1!
Gary
>
> My 2 cents
Re: [BCEL] 5.3 is going to be messy
Posted by Torsten Curdt <tc...@vafer.org>.
>
> 1) I don't believe we should force users to migrate their code in
> order to support java 7/8.
>
...and that line of thinking is why it feels like commons projects are
effectively stuck in the past.
No one needs to upgrade. If your projects live in the past - there are bug
fix releases.
But if you want the new shiny then you as well should be OK to put in some
effort to do so.
Change should be easy - not just for our user but also for us.
My 2 cents
Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going
to be messy)
Posted by Benedikt Ritter <br...@apache.org>.
Andrey Loskutov <lo...@gmx.de> schrieb am Di., 7. Juni 2016 um 19:49 Uhr:
> On Tuesday 07 June 2016 17:01 Benedikt Ritter wrote:
> > Okay.
> >
> > - I'm going to revert the package rename.
> > - We're going to create a binary compatible release for Java 7 and Java 8
> > support.
> > - We will bump the major version number to indicate that there are
> massive
> > changes in this release.
>
> I *really* appreciate your effort and your time!
> It is hard to change decisions and it is hard to maintain compatibility,
> so many thanks!
> I hope to see and to try out the changes soon.
>
You're welcome. The changes should be mirrored to GitHub soon. Furthermore
I've configured a jenkins build which should push the artifacts to the
Apache Snapshot repository. You can use that for testing.
Benedikt
>
> --
> Kind regards,
> google.com/+AndreyLoskutov
>
Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going to be messy)
Posted by Andrey Loskutov <lo...@gmx.de>.
On Tuesday 07 June 2016 17:01 Benedikt Ritter wrote:
> Okay.
>
> - I'm going to revert the package rename.
> - We're going to create a binary compatible release for Java 7 and Java 8
> support.
> - We will bump the major version number to indicate that there are massive
> changes in this release.
I *really* appreciate your effort and your time!
It is hard to change decisions and it is hard to maintain compatibility, so many thanks!
I hope to see and to try out the changes soon.
--
Kind regards,
google.com/+AndreyLoskutov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going
to be messy)
Posted by Benedikt Ritter <br...@apache.org>.
I messed up the rename. I'm currently fixing that.
Benedikt Ritter <br...@apache.org> schrieb am Di., 7. Juni 2016 um
19:01 Uhr:
> Okay.
>
> - I'm going to revert the package rename.
> - We're going to create a binary compatible release for Java 7 and Java 8
> support.
> - We will bump the major version number to indicate that there are massive
> changes in this release.
>
> Benedikt
>
> sebb <se...@gmail.com> schrieb am Di., 7. Juni 2016 um 18:16 Uhr:
>
>> Also need to revert the Maven GA coords
>>
>> On 7 June 2016 at 17:06, sebb <se...@gmail.com> wrote:
>> > Fine by me
>> >
>> > On 7 June 2016 at 17:00, Benedikt Ritter <br...@apache.org> wrote:
>> >> Hi,
>> >>
>> >> any objections against reverting the package rename in trunk back to
>> >> org.apache.bcel ? (For reasons see below)
>> >>
>> >> Benedikt
>> >>
>> >> ---------- Forwarded message ---------
>> >> From: Andrey Loskutov <lo...@gmx.de>
>> >> Date: Di., 7. Juni 2016 um 17:55 Uhr
>> >> Subject: Re: [BCEL] 5.3 is going to be messy
>> >> To: <de...@commons.apache.org>
>> >> Cc: Benedikt Ritter <br...@apache.org>
>> >>
>> >>
>> >> On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
>> >>> > > 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.
>> >>> >
>> >>> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS*
>> the
>> >>> > Java 7/8 compatibility.
>> >>> > We (user) just want something stable we can use on a modern JVM (and
>> >> Java
>> >>> > 7 is already *obsoleted*!), nothing more.
>> >>> > Before thinking about new API's, please just release something
>> running
>> >> on
>> >>> > Java 7/8.
>> >>> >
>> >>>
>> >>> So that's a word from our users.
>> >>>
>> >>> What now? Revert the Package rename in trunk back to org.apache.bcel
>> and
>> >>> finish that 5.3 release? I have no idea what's broken wrt to
>> compatibility
>> >>> because you cant compare with the ne coords anymore.
>> >>
>> >> Yes. Please undo "package rename" aka BCEL-222 thing first.
>> >> This is an easy task (requires ~5 minutes in the IDE), see commit
>> >>
>> https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
>> >> . After that we will see how bad/good the state is.
>> >> I don't think the state is really bad, otherwise I wouldn't be able to
>> >> create experimental port of FB in few hours.
>> >> See https://github.com/findbugsproject/findbugs/issues/106 - the
>> commits
>> >> referenced there describe what I saw on breakage from the FindBugs
>> side.
>> >> Of course that is only from the FindBugs point of view.
>> >>
>> >>
>> >> --
>> >> Kind regards,
>> >> google.com/+AndreyLoskutov
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going
to be messy)
Posted by Benedikt Ritter <br...@apache.org>.
Okay.
- I'm going to revert the package rename.
- We're going to create a binary compatible release for Java 7 and Java 8
support.
- We will bump the major version number to indicate that there are massive
changes in this release.
Benedikt
sebb <se...@gmail.com> schrieb am Di., 7. Juni 2016 um 18:16 Uhr:
> Also need to revert the Maven GA coords
>
> On 7 June 2016 at 17:06, sebb <se...@gmail.com> wrote:
> > Fine by me
> >
> > On 7 June 2016 at 17:00, Benedikt Ritter <br...@apache.org> wrote:
> >> Hi,
> >>
> >> any objections against reverting the package rename in trunk back to
> >> org.apache.bcel ? (For reasons see below)
> >>
> >> Benedikt
> >>
> >> ---------- Forwarded message ---------
> >> From: Andrey Loskutov <lo...@gmx.de>
> >> Date: Di., 7. Juni 2016 um 17:55 Uhr
> >> Subject: Re: [BCEL] 5.3 is going to be messy
> >> To: <de...@commons.apache.org>
> >> Cc: Benedikt Ritter <br...@apache.org>
> >>
> >>
> >> On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
> >>> > > 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.
> >>> >
> >>> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS*
> the
> >>> > Java 7/8 compatibility.
> >>> > We (user) just want something stable we can use on a modern JVM (and
> >> Java
> >>> > 7 is already *obsoleted*!), nothing more.
> >>> > Before thinking about new API's, please just release something
> running
> >> on
> >>> > Java 7/8.
> >>> >
> >>>
> >>> So that's a word from our users.
> >>>
> >>> What now? Revert the Package rename in trunk back to org.apache.bcel
> and
> >>> finish that 5.3 release? I have no idea what's broken wrt to
> compatibility
> >>> because you cant compare with the ne coords anymore.
> >>
> >> Yes. Please undo "package rename" aka BCEL-222 thing first.
> >> This is an easy task (requires ~5 minutes in the IDE), see commit
> >>
> https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
> >> . After that we will see how bad/good the state is.
> >> I don't think the state is really bad, otherwise I wouldn't be able to
> >> create experimental port of FB in few hours.
> >> See https://github.com/findbugsproject/findbugs/issues/106 - the
> commits
> >> referenced there describe what I saw on breakage from the FindBugs side.
> >> Of course that is only from the FindBugs point of view.
> >>
> >>
> >> --
> >> Kind regards,
> >> google.com/+AndreyLoskutov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going
to be messy)
Posted by sebb <se...@gmail.com>.
Also need to revert the Maven GA coords
On 7 June 2016 at 17:06, sebb <se...@gmail.com> wrote:
> Fine by me
>
> On 7 June 2016 at 17:00, Benedikt Ritter <br...@apache.org> wrote:
>> Hi,
>>
>> any objections against reverting the package rename in trunk back to
>> org.apache.bcel ? (For reasons see below)
>>
>> Benedikt
>>
>> ---------- Forwarded message ---------
>> From: Andrey Loskutov <lo...@gmx.de>
>> Date: Di., 7. Juni 2016 um 17:55 Uhr
>> Subject: Re: [BCEL] 5.3 is going to be messy
>> To: <de...@commons.apache.org>
>> Cc: Benedikt Ritter <br...@apache.org>
>>
>>
>> On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
>>> > > 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.
>>> >
>>> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
>>> > Java 7/8 compatibility.
>>> > We (user) just want something stable we can use on a modern JVM (and
>> Java
>>> > 7 is already *obsoleted*!), nothing more.
>>> > Before thinking about new API's, please just release something running
>> on
>>> > Java 7/8.
>>> >
>>>
>>> So that's a word from our users.
>>>
>>> What now? Revert the Package rename in trunk back to org.apache.bcel and
>>> finish that 5.3 release? I have no idea what's broken wrt to compatibility
>>> because you cant compare with the ne coords anymore.
>>
>> Yes. Please undo "package rename" aka BCEL-222 thing first.
>> This is an easy task (requires ~5 minutes in the IDE), see commit
>> https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
>> . After that we will see how bad/good the state is.
>> I don't think the state is really bad, otherwise I wouldn't be able to
>> create experimental port of FB in few hours.
>> See https://github.com/findbugsproject/findbugs/issues/106 - the commits
>> referenced there describe what I saw on breakage from the FindBugs side.
>> Of course that is only from the FindBugs point of view.
>>
>>
>> --
>> Kind regards,
>> google.com/+AndreyLoskutov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going
to be messy)
Posted by sebb <se...@gmail.com>.
Fine by me
On 7 June 2016 at 17:00, Benedikt Ritter <br...@apache.org> wrote:
> Hi,
>
> any objections against reverting the package rename in trunk back to
> org.apache.bcel ? (For reasons see below)
>
> Benedikt
>
> ---------- Forwarded message ---------
> From: Andrey Loskutov <lo...@gmx.de>
> Date: Di., 7. Juni 2016 um 17:55 Uhr
> Subject: Re: [BCEL] 5.3 is going to be messy
> To: <de...@commons.apache.org>
> Cc: Benedikt Ritter <br...@apache.org>
>
>
> On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
>> > > 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.
>> >
>> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
>> > Java 7/8 compatibility.
>> > We (user) just want something stable we can use on a modern JVM (and
> Java
>> > 7 is already *obsoleted*!), nothing more.
>> > Before thinking about new API's, please just release something running
> on
>> > Java 7/8.
>> >
>>
>> So that's a word from our users.
>>
>> What now? Revert the Package rename in trunk back to org.apache.bcel and
>> finish that 5.3 release? I have no idea what's broken wrt to compatibility
>> because you cant compare with the ne coords anymore.
>
> Yes. Please undo "package rename" aka BCEL-222 thing first.
> This is an easy task (requires ~5 minutes in the IDE), see commit
> https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
> . After that we will see how bad/good the state is.
> I don't think the state is really bad, otherwise I wouldn't be able to
> create experimental port of FB in few hours.
> See https://github.com/findbugsproject/findbugs/issues/106 - the commits
> referenced there describe what I saw on breakage from the FindBugs side.
> Of course that is only from the FindBugs point of view.
>
>
> --
> Kind regards,
> google.com/+AndreyLoskutov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going to be messy)
Posted by Benedikt Ritter <br...@apache.org>.
Hi,
any objections against reverting the package rename in trunk back to
org.apache.bcel ? (For reasons see below)
Benedikt
---------- Forwarded message ---------
From: Andrey Loskutov <lo...@gmx.de>
Date: Di., 7. Juni 2016 um 17:55 Uhr
Subject: Re: [BCEL] 5.3 is going to be messy
To: <de...@commons.apache.org>
Cc: Benedikt Ritter <br...@apache.org>
On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
> > > 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.
> >
> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
> > Java 7/8 compatibility.
> > We (user) just want something stable we can use on a modern JVM (and
Java
> > 7 is already *obsoleted*!), nothing more.
> > Before thinking about new API's, please just release something running
on
> > Java 7/8.
> >
>
> So that's a word from our users.
>
> What now? Revert the Package rename in trunk back to org.apache.bcel and
> finish that 5.3 release? I have no idea what's broken wrt to compatibility
> because you cant compare with the ne coords anymore.
Yes. Please undo "package rename" aka BCEL-222 thing first.
This is an easy task (requires ~5 minutes in the IDE), see commit
https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
. After that we will see how bad/good the state is.
I don't think the state is really bad, otherwise I wouldn't be able to
create experimental port of FB in few hours.
See https://github.com/findbugsproject/findbugs/issues/106 - the commits
referenced there describe what I saw on breakage from the FindBugs side.
Of course that is only from the FindBugs point of view.
--
Kind regards,
google.com/+AndreyLoskutov
Re: [BCEL] 5.3 is going to be messy
Posted by Andrey Loskutov <lo...@gmx.de>.
On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
> > > 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.
> >
> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
> > Java 7/8 compatibility.
> > We (user) just want something stable we can use on a modern JVM (and Java
> > 7 is already *obsoleted*!), nothing more.
> > Before thinking about new API's, please just release something running on
> > Java 7/8.
> >
>
> So that's a word from our users.
>
> What now? Revert the Package rename in trunk back to org.apache.bcel and
> finish that 5.3 release? I have no idea what's broken wrt to compatibility
> because you cant compare with the ne coords anymore.
Yes. Please undo "package rename" aka BCEL-222 thing first.
This is an easy task (requires ~5 minutes in the IDE), see commit https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
. After that we will see how bad/good the state is.
I don't think the state is really bad, otherwise I wouldn't be able to create experimental port of FB in few hours.
See https://github.com/findbugsproject/findbugs/issues/106 - the commits referenced there describe what I saw on breakage from the FindBugs side.
Of course that is only from the FindBugs point of view.
--
Kind regards,
google.com/+AndreyLoskutov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Benedikt Ritter <br...@apache.org>.
Hello,
Andrey Loskutov <lo...@gmx.de> schrieb am Di., 7. Juni 2016 um 17:35 Uhr:
> On Tuesday 07 June 2016 15:24 Benedikt Ritter wrote:
> > Hi,
> >
> > sebb <se...@gmail.com> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
> > > 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.
>
> What trouble do you mean? BTW if I can help testing, I'm ready to go.
>
> > 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.
>
> Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
> Java 7/8 compatibility.
> We (user) just want something stable we can use on a modern JVM (and Java
> 7 is already *obsoleted*!), nothing more.
> Before thinking about new API's, please just release something running on
> Java 7/8.
>
So that's a word from our users.
What now? Revert the Package rename in trunk back to org.apache.bcel and
finish that 5.3 release? I have no idea what's broken wrt to compatibility
because you cant compare with the ne coords anymore.
>
> --
> Kind regards,
> google.com/+AndreyLoskutov
>
Re: [BCEL] 5.3 is going to be messy
Posted by Andrey Loskutov <lo...@gmx.de>.
On Tuesday 07 June 2016 15:24 Benedikt Ritter wrote:
> Hi,
>
> sebb <se...@gmail.com> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
> > 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.
What trouble do you mean? BTW if I can help testing, I'm ready to go.
> 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.
Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the Java 7/8 compatibility.
We (user) just want something stable we can use on a modern JVM (and Java 7 is already *obsoleted*!), nothing more.
Before thinking about new API's, please just release something running on Java 7/8.
--
Kind regards,
google.com/+AndreyLoskutov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <br...@apache.org> wrote:
>
> Hi,
>
> sebb <se...@gmail.com> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
>
>> On 6 June 2016 at 21:02, Gary Gregory <ga...@gmail.com> wrote:
>>> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <br...@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
>>
>>
Re: [BCEL] 5.3 is going to be messy
Posted by Benedikt Ritter <br...@apache.org>.
Hi,
sebb <se...@gmail.com> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
> On 6 June 2016 at 21:02, Gary Gregory <ga...@gmail.com> wrote:
> > On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <br...@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
>
>
Re: [BCEL] 5.3 is going to be messy
Posted by sebb <se...@gmail.com>.
On 6 June 2016 at 21:02, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <br...@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.
> 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
Re: [BCEL] 5.3 is going to be messy
Posted by Jörg Schaible <jo...@gmx.de>.
Gary Gregory wrote:
> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <br...@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.
>
> 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.
+1
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] 5.3 is going to be messy
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <br...@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.
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