You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2014/09/27 09:50:15 UTC
[VOTE] Release BCEL 6.0 based on RC3
Hi all,
The third release candidate of BCEL is ready to pass under your scrutiny.
Tag:
http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC3/
(r1627908)
Release notes:
http://people.apache.org/~ebourg/bcel/RELEASE-NOTES.txt
Distribution files:
http://people.apache.org/~ebourg/bcel/
Checksums (sha1):
6f1d11224b7cea98ffbffa25d69d759fcd47421c bcel-6.0-bin.tar.gz
425729b886f72481bdbfc7e8ca108f20c00e67ef bcel-6.0-bin.zip
89e171be63df397d23ea746f9845cf3087e8467e bcel-6.0-src.tar.gz
a03c2e605b8eb997b5d023d6a7d6aa54fbf3600e bcel-6.0-src.zip
Site:
http://people.apache.org/~ebourg/bcel/site/
Javadoc:
http://people.apache.org/~ebourg/bcel/site/apidocs/
Maven artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-1047/org/apache/bcel/bcel/6.0/
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you for your reviews,
Emmanuel Bourg
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2014 14:58, sebb a écrit :
> Sigs are necessary but not sufficient - the published artifacts must
> also have at least one hash.
I added the hashes.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 28 September 2014 07:53, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 28/09/2014 02:36, sebb a écrit :
>
>> -1 hashes are missing from the directory
>
> The directory contains the PGP signatures, that's even better.
Sigs are necessary but not sufficient - the published artifacts must
also have at least one hash.
aroun
>> Link to KEYS file is needed in the vote e-mail thread
>
> As usual that's the KEYS file of the Apache Commons project, no need to
> repeat it in every vote for a Commons component.
The point is to ensure that reviewers have all the information they
need without having to search for it.
This is an open source project; we should make it possible for anyone
following the dev list to review the RC.
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2014 02:36, sebb a écrit :
> -1 hashes are missing from the directory
The directory contains the PGP signatures, that's even better.
> Link to KEYS file is needed in the vote e-mail thread
As usual that's the KEYS file of the Apache Commons project, no need to
repeat it in every vote for a Commons component.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 27 September 2014 08:50, Emmanuel Bourg <eb...@apache.org> wrote:
> Hi all,
>
> The third release candidate of BCEL is ready to pass under your scrutiny.
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC3/
> (r1627908)
>
> Release notes:
> http://people.apache.org/~ebourg/bcel/RELEASE-NOTES.txt
>
> Distribution files:
> http://people.apache.org/~ebourg/bcel/
-1 hashes are missing from the directory
Link to KEYS file is needed in the vote e-mail thread
> Checksums (sha1):
> 6f1d11224b7cea98ffbffa25d69d759fcd47421c bcel-6.0-bin.tar.gz
> 425729b886f72481bdbfc7e8ca108f20c00e67ef bcel-6.0-bin.zip
> 89e171be63df397d23ea746f9845cf3087e8467e bcel-6.0-src.tar.gz
> a03c2e605b8eb997b5d023d6a7d6aa54fbf3600e bcel-6.0-src.zip
>
> Site:
> http://people.apache.org/~ebourg/bcel/site/
>
> Javadoc:
> http://people.apache.org/~ebourg/bcel/site/apidocs/
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapachecommons-1047/org/apache/bcel/bcel/6.0/
>
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you for your reviews,
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
Adding a clear method seems reasonable for app that are "long" running.
Gary
On Tue, Oct 7, 2014 at 8:00 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 07/10/2014 13:51, Gary Gregory a écrit :
>
> > Can you flush it? Can you disable it?
>
> No, but the size retained is reasonable.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 07/10/2014 13:51, Gary Gregory a écrit :
> Can you flush it? Can you disable it?
No, but the size retained is reasonable.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 7, 2014 at 7:48 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 07/10/2014 11:26, Emmanuel Bourg a écrit :
>
> > If nobody object I'll remove this cache, the impact on the performance
> > is too important to enable it by default, and the static state smells
> > like a quick and dirty implementation. This feature could return as a
> > pluggable cache if someone wants to provide a patch.
>
> I looked at the cache in ObjectType, this one keeps only 200 instances.
> When parsing rt.jar it saved 92% of the ObjectType instances and ~13MB
> of memory. The overhead was about 7% (820ms instead of 767ms).
>
> I wonder if this one is worth keeping.
>
Can you flush it? Can you disable it?
Gary
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 07/10/2014 11:26, Emmanuel Bourg a écrit :
> If nobody object I'll remove this cache, the impact on the performance
> is too important to enable it by default, and the static state smells
> like a quick and dirty implementation. This feature could return as a
> pluggable cache if someone wants to provide a patch.
I looked at the cache in ObjectType, this one keeps only 200 instances.
When parsing rt.jar it saved 92% of the ObjectType instances and ~13MB
of memory. The overhead was about 7% (820ms instead of 767ms).
I wonder if this one is worth keeping.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 30/09/2014 14:15, Konstantin Kolinko a écrit :
> AFAIK jars from JIRA web application were used for the test. From
> comment on commit that removed the cache, the difference was 10-15%,
> for our copy of BCEL that already had other optimizations (code
> removal) applied:
I ran the PerformanceTest class applied on the rt.jar file from Java 8.
For ClassParser.parse() I get 1300ms when the cache is enabled, and
820ms without (~37% faster). Using a HashMap instead of a LinkedHashMap
is slightly faster (1200ms) but the cache entries are no longer evicted
automatically.
On the memory side, the benefit of the cache was more perceptible.
Parsing rt.jar created ~10MB of ConstantUtf8 instances with the cache
enabled, and 27MB without. At the end the cache retained 20000 instances
for a total of ~450KB and there is no way to clear it.
If nobody object I'll remove this cache, the impact on the performance
is too important to enable it by default, and the static state smells
like a quick and dirty implementation. This feature could return as a
pluggable cache if someone wants to provide a patch.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-09-30 14:50 GMT+04:00 Emmanuel Bourg <eb...@apache.org>:
> Hi Konstantin,
>
> Thank you very much for the feedback.
>
>> I have the following concerns:
>>
>> 1) Someone was testing Tomcat usage of BCEL and found that using this
>> caching did not improve performance, but reduced it for our use case.
>> It was reported in the following Bugzilla issue:
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=56940
>
> Do you have more details on the size of the jars used to measure the
> performance? Did the test let enough time for the JIT to kick in?
It was Mark Thomas who did the testing. Maybe he will add something to
the discussion.
AFAIK jars from JIRA web application were used for the test. From
comment on commit that removed the cache, the difference was 10-15%,
for our copy of BCEL that already had other optimizations (code
removal) applied:
http://svn.apache.org/r1624476
The test code:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/tags/TOMCAT_8_0_14/test/org/apache/tomcat/util/bcel/TesterPerformance.java?view=markup
>> 2) Configuration of this cache depends on reading System properties such as
>>
>> final static boolean BCEL_DONT_CACHE = Boolean.getBoolean("bcel.dontCache");
>>
>> It is a bit odd to me to configure a library via system properties.
>>
>> At least there could be a static setter for that flag, or a static
>> setter for a cache instance / a factory class.
>
> I agree, a system property was probably good for Findbugs if it forks
> its own VM, but not for a general purpose library.
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Hi Konstantin,
Thank you very much for the feedback.
> I have the following concerns:
>
> 1) Someone was testing Tomcat usage of BCEL and found that using this
> caching did not improve performance, but reduced it for our use case.
> It was reported in the following Bugzilla issue:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56940
Do you have more details on the size of the jars used to measure the
performance? Did the test let enough time for the JIT to kick in?
> 2) Configuration of this cache depends on reading System properties such as
>
> final static boolean BCEL_DONT_CACHE = Boolean.getBoolean("bcel.dontCache");
>
> It is a bit odd to me to configure a library via system properties.
>
> At least there could be a static setter for that flag, or a static
> setter for a cache instance / a factory class.
I agree, a system property was probably good for Findbugs if it forks
its own VM, but not for a general purpose library.
> 3) RELEASE-NOTES.txt describes this change as
>
> [BCEL-163] Incorporate patch file from Findbugs
>
> which does not say much about this change.
>
> Actually this change introduced caching for ConstantUtf8 and
> ObjectType instances.
I'll update it if I roll a new RC.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-09-27 11:50 GMT+04:00 Emmanuel Bourg <eb...@apache.org>:
> Hi all,
>
> The third release candidate of BCEL is ready to pass under your scrutiny.
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC3/
> (r1627908)
>
> Release notes:
> http://people.apache.org/~ebourg/bcel/RELEASE-NOTES.txt
>
> Distribution files:
> http://people.apache.org/~ebourg/bcel/
>
> Checksums (sha1):
> 6f1d11224b7cea98ffbffa25d69d759fcd47421c bcel-6.0-bin.tar.gz
> 425729b886f72481bdbfc7e8ca108f20c00e67ef bcel-6.0-bin.zip
> 89e171be63df397d23ea746f9845cf3087e8467e bcel-6.0-src.tar.gz
> a03c2e605b8eb997b5d023d6a7d6aa54fbf3600e bcel-6.0-src.zip
>
> Site:
> http://people.apache.org/~ebourg/bcel/site/
>
> Javadoc:
> http://people.apache.org/~ebourg/bcel/site/apidocs/
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapachecommons-1047/org/apache/bcel/bcel/6.0/
>
Hi!
I was reviewing the Clirr report and noted new methods that introduced
caching into classfile.ConstantUtf8 class,
such as methods ConstantUtf8.getCachedInstance()
The code originates from the following commit and JIRA issue:
http://svn.apache.org/r1481383
https://issues.apache.org/jira/browse/BCEL-163
I have the following concerns:
1) Someone was testing Tomcat usage of BCEL and found that using this
caching did not improve performance, but reduced it for our use case.
It was reported in the following Bugzilla issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56940
2) Configuration of this cache depends on reading System properties such as
final static boolean BCEL_DONT_CACHE = Boolean.getBoolean("bcel.dontCache");
It is a bit odd to me to configure a library via system properties.
At least there could be a static setter for that flag, or a static
setter for a cache instance / a factory class.
3) RELEASE-NOTES.txt describes this change as
[BCEL-163] Incorporate patch file from Findbugs
which does not say much about this change.
Actually this change introduced caching for ConstantUtf8 and
ObjectType instances.
My experience with BCEL comes from Apache Tomcat. Tomcat uses a copy
of BCEL code. It is used to perform scanning for class-level
annotations across class files. During profiling and refactoring
several weeks ago a lot of code that is not needed for our use case
was removed from our copy. The caching code was one of them.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 27/09/2014 15:48, Oliver Heger a écrit :
> - The distribution files of other Commons components start with the
> commons- prefix. This is not the case here.
Because BCEL wasn't a Commons project and still distributed under it's
own org.apache.bcel groupId
> I am not sure how problematic the wrong copyright year is, also from a
> legal PoV. This prevents me from voting +1; everything else is not
> blocking.
I guess that may mislead someone into thinking the copyright will expire
2 years before it actually should. We are talking about the life time of
the authors + 50 or 70 years depending the country. I don't think that
really matters.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Oliver Heger <ol...@oliver-heger.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Build works fine with Java 1.5 and 1.7 on Windows 8.1. Artifacts look
good. The site shows that the code base probably needs some work to
improve quality, but this does not block the release.
Nits:
- - The NOTICE file states the wrong copyright year.
- - The distribution files of other Commons components start with the
commons- prefix. This is not the case here.
I am not sure how problematic the wrong copyright year is, also from a
legal PoV. This prevents me from voting +1; everything else is not
blocking.
Oliver
Am 27.09.2014 um 09:50 schrieb Emmanuel Bourg:
> Hi all,
>
> The third release candidate of BCEL is ready to pass under your
> scrutiny.
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC3/
>
>
(r1627908)
>
> Release notes:
> http://people.apache.org/~ebourg/bcel/RELEASE-NOTES.txt
>
> Distribution files: http://people.apache.org/~ebourg/bcel/
>
> Checksums (sha1): 6f1d11224b7cea98ffbffa25d69d759fcd47421c
> bcel-6.0-bin.tar.gz 425729b886f72481bdbfc7e8ca108f20c00e67ef
> bcel-6.0-bin.zip 89e171be63df397d23ea746f9845cf3087e8467e
> bcel-6.0-src.tar.gz a03c2e605b8eb997b5d023d6a7d6aa54fbf3600e
> bcel-6.0-src.zip
>
> Site: http://people.apache.org/~ebourg/bcel/site/
>
> Javadoc: http://people.apache.org/~ebourg/bcel/site/apidocs/
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapachecommons-1047/org/apache/bcel/bcel/6.0/
>
>
>
> Please review the release candidate and vote. This vote will close
> no sooner that 72 hours from now.
>
> [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but
> really should fix... [ ] -1 I oppose this release because...
>
> Thank you for your reviews,
>
> Emmanuel Bourg
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUJsAyAAoJEDgk3dGBGEE4j18IALlBJsgK9Kf0APSQdst8Idui
65zuBrApxqy/dpxT51m8egk8zWasG+PIu686jAjcs9Hwj23STtHKX0DXKnQVCw6Q
mrsnnxHZZ4BHRFp8PUeu6kKz+KuTOVmJmoHBg+DusbHkxCD07bIFxHx81v200tbG
UHOSE/+tdSo7urOC98YTMZ1Ikg+zonRG2GTE1PWgNXsS+E/wM/U0y3MFkEEUginV
FGWscZgflUcBJkME9J5trvDM14khFQi6OmpZKNk4Ld54N6NmoM15Tq4nsDWSKhNX
050R4Cg1W2onmZLlBy/Vox3owTvM9B+jh3hn7CmlNpSVH88dG3A+FcB6QFSXGf4=
=lDGf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 02/03/2015 23:21, ianmca86 a écrit :
> i don't like the policy of changing the package name to make a tiny change
> to binary compatibility. it makes it impossible to release often
And users don't like having deep conflicting libraries in their
dependency tree :)
> but we're getting way off base. my question is the same as ben's which was
> never answered. can we check in the patch for 209 and then release a new
> version?
There are other important issues besides BCEL-209, the LVTT issues
should be fixed for example if we want to claim Java 5 support.
If your company needs a BCEL version compatible with Java 8 you can
compile the version from the 6.0-RC3 tag, it isn't perfect but still
better than the latest stable release.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
WRT Tangent: The thing with BC is that it's a Boolean property, not a
quantitative...
On Mon, Mar 2, 2015 at 2:21 PM, ianmca86 <ia...@gmail.com> wrote:
> i don't like the policy of changing the package name to make a tiny change
> to binary compatibility. it makes it impossible to release often
>
> but we're getting way off base. my question is the same as ben's which was
> never answered. can we check in the patch for 209 and then release a new
> version?
>
>
> On Mon, Mar 2, 2015 at 2:04 PM, garydgregory [via Apache Commons] <
> ml-node+s680414n4673389h91@n4.nabble.com> wrote:
>
> > On Mon, Mar 2, 2015 at 2:07 PM, sebb <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=0>> wrote:
> >
> > > On 2 March 2015 at 21:33, Gary Gregory <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=1>> wrote:
> > > > I'm all for RERO if the release manager is willing.
> > >
> > > RM willingness is only part of it.
> > >
> > > RERO is all very well if:
> > > - the API is stable; or
> > > - frequent changes of package name/Maven coords are acceptable to
> > > consumers; or
> > > - one does not care about binary compatibilty
> > >
> > > IMO it's unhelpful to keep pushing the RERO mantra in isolation.
> > >
> >
> > Yes, agreed. I was assuming we all see eye to eye on the semantics.
> >
> > Gary
> >
> > >
> > > > Gary
> > > >
> > > > On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=2>> wrote:
> > > >
> > > >> +1
> > > >>
> > > >> no one has really answered ben's question yet. if bcel 209
> > > >> <https://issues.apache.org/jira/browse/BCEL-209> is committed
> > could
> > > we
> > > >> cut
> > > >> a release? it seems like everyone is okay with the general approach
> > > taken
> > > >> there
> > > >>
> > > >> my company also is mandating all projects move to java 8 this month
> > > since
> > > >> java 7 is discontinued next month. i'm quite nervous that patch has
> > been
> > > >> outstanding for a month already and we're blocking on it. nine years
> > is
> > > too
> > > >> long between releases and we don't need to drag this out more
> > > >>
> > > >> regards
> > > >> ian
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context:
> > > >>
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> > > >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=3>
> > > >> For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=4>
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > E-Mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=5> | [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=6>
> > > > 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: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=7>
> > > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=8>
> > >
> > >
> >
> >
> > --
> > E-Mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=9> | [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=10>
> > 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
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673389.html
> > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> >
> > .
> > NAML
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673390.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by ianmca86 <ia...@gmail.com>.
i don't like the policy of changing the package name to make a tiny change
to binary compatibility. it makes it impossible to release often
but we're getting way off base. my question is the same as ben's which was
never answered. can we check in the patch for 209 and then release a new
version?
On Mon, Mar 2, 2015 at 2:04 PM, garydgregory [via Apache Commons] <
ml-node+s680414n4673389h91@n4.nabble.com> wrote:
> On Mon, Mar 2, 2015 at 2:07 PM, sebb <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=0>> wrote:
>
> > On 2 March 2015 at 21:33, Gary Gregory <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=1>> wrote:
> > > I'm all for RERO if the release manager is willing.
> >
> > RM willingness is only part of it.
> >
> > RERO is all very well if:
> > - the API is stable; or
> > - frequent changes of package name/Maven coords are acceptable to
> > consumers; or
> > - one does not care about binary compatibilty
> >
> > IMO it's unhelpful to keep pushing the RERO mantra in isolation.
> >
>
> Yes, agreed. I was assuming we all see eye to eye on the semantics.
>
> Gary
>
> >
> > > Gary
> > >
> > > On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=2>> wrote:
> > >
> > >> +1
> > >>
> > >> no one has really answered ben's question yet. if bcel 209
> > >> <https://issues.apache.org/jira/browse/BCEL-209> is committed
> could
> > we
> > >> cut
> > >> a release? it seems like everyone is okay with the general approach
> > taken
> > >> there
> > >>
> > >> my company also is mandating all projects move to java 8 this month
> > since
> > >> java 7 is discontinued next month. i'm quite nervous that patch has
> been
> > >> outstanding for a month already and we're blocking on it. nine years
> is
> > too
> > >> long between releases and we don't need to drag this out more
> > >>
> > >> regards
> > >> ian
> > >>
> > >>
> > >>
> > >> --
> > >> View this message in context:
> > >>
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> > >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=3>
> > >> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=4>
> > >>
> > >>
> > >
> > >
> > > --
> > > E-Mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=5> | [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=6>
> > > 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: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=7>
> > For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=8>
> >
> >
>
>
> --
> E-Mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=9> | [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=10>
> 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
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673389.html
> To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy>
> .
> NAML
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673390.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 13 March 2015 at 17:40, Sarah Murray <sa...@gmail.com> wrote:
> It's absurd to have a library where no released version works on any
> supported version of Java. End of story
Well, there are 2 solutions to that.
1) BCEL is abandoned/retired.
2) BCEL is updated to support recent versions of Java.
> On Wed, Mar 11, 2015 at 7:04 PM, sebb <se...@gmail.com> wrote:
>
>> On 12 March 2015 at 01:25, Niall Pemberton <ni...@gmail.com>
>> wrote:
>> > On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com>
>> wrote:
>> >
>> >> +100 to RERO. +1000 to release before we're all dead. It's been a decade
>> >> people. Just cut a release already. You can always cut another one
>> later.
>> >> Stop with the excuses
>> >>
>> >> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
>> >> users are left in a lurch. Compiling libraries is not a realistic
>> solution.
>> >> As stated previously by others we would also have to patch and compile
>> >> libraries depending on BCEL and also figure the transitive dependency
>> graph
>> >> for everything we use since we can't use Maven to do that due to BCEL
>> not
>> >> being in Maven. This is a huge huge pain because we're big Scala users
>> and
>> >> rely heavily on the Typesafe ecosystem which is dropping support for
>> Java 7
>> >> in all of its products and already has in Play Framework and Akka as
>> well
>> >> as
>> >> others like its Config library.
>> >>
>> >
>> > You say "stop with the excuses" and then go on to list a whole bunch of
>> > excuses why its too much effort for you to build BCEL and test it. Yes it
>> > would be an effort - but it would be invaluable to have some pre-release
>> > testing and feedback and help to get it our faster.
>>
>> It's not even necessary to build BCEL in order to test against trunk,
>> because you can get BCEL snapshots from the Apache Maven Snapshot
>> repository.
>> If the CI system is working, the SNAPSHOTs wll be updated regularly
>> when there have been commits.
>> If it appears that the snapshot has not been built for some while
>> since the last commit (e.g. 24 hrs), ask here and someone can prod the
>> CI system (or just deploy another snapshot).
>>
>> Of course such builds have no guarantees, and should not be relied on
>> long-term (they may be replaced at any time), but for test purposes
>> they will do.
>>
>> > Niall
>> >
>> >
>> >
>> >> --S.
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
>> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Sarah Murray <sa...@gmail.com>.
It's absurd to have a library where no released version works on any
supported version of Java. End of story
On Wed, Mar 11, 2015 at 7:04 PM, sebb <se...@gmail.com> wrote:
> On 12 March 2015 at 01:25, Niall Pemberton <ni...@gmail.com>
> wrote:
> > On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com>
> wrote:
> >
> >> +100 to RERO. +1000 to release before we're all dead. It's been a decade
> >> people. Just cut a release already. You can always cut another one
> later.
> >> Stop with the excuses
> >>
> >> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
> >> users are left in a lurch. Compiling libraries is not a realistic
> solution.
> >> As stated previously by others we would also have to patch and compile
> >> libraries depending on BCEL and also figure the transitive dependency
> graph
> >> for everything we use since we can't use Maven to do that due to BCEL
> not
> >> being in Maven. This is a huge huge pain because we're big Scala users
> and
> >> rely heavily on the Typesafe ecosystem which is dropping support for
> Java 7
> >> in all of its products and already has in Play Framework and Akka as
> well
> >> as
> >> others like its Config library.
> >>
> >
> > You say "stop with the excuses" and then go on to list a whole bunch of
> > excuses why its too much effort for you to build BCEL and test it. Yes it
> > would be an effort - but it would be invaluable to have some pre-release
> > testing and feedback and help to get it our faster.
>
> It's not even necessary to build BCEL in order to test against trunk,
> because you can get BCEL snapshots from the Apache Maven Snapshot
> repository.
> If the CI system is working, the SNAPSHOTs wll be updated regularly
> when there have been commits.
> If it appears that the snapshot has not been built for some while
> since the last commit (e.g. 24 hrs), ask here and someone can prod the
> CI system (or just deploy another snapshot).
>
> Of course such builds have no guarantees, and should not be relied on
> long-term (they may be replaced at any time), but for test purposes
> they will do.
>
> > Niall
> >
> >
> >
> >> --S.
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> 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: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 12 March 2015 at 01:25, Niall Pemberton <ni...@gmail.com> wrote:
> On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com> wrote:
>
>> +100 to RERO. +1000 to release before we're all dead. It's been a decade
>> people. Just cut a release already. You can always cut another one later.
>> Stop with the excuses
>>
>> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
>> users are left in a lurch. Compiling libraries is not a realistic solution.
>> As stated previously by others we would also have to patch and compile
>> libraries depending on BCEL and also figure the transitive dependency graph
>> for everything we use since we can't use Maven to do that due to BCEL not
>> being in Maven. This is a huge huge pain because we're big Scala users and
>> rely heavily on the Typesafe ecosystem which is dropping support for Java 7
>> in all of its products and already has in Play Framework and Akka as well
>> as
>> others like its Config library.
>>
>
> You say "stop with the excuses" and then go on to list a whole bunch of
> excuses why its too much effort for you to build BCEL and test it. Yes it
> would be an effort - but it would be invaluable to have some pre-release
> testing and feedback and help to get it our faster.
It's not even necessary to build BCEL in order to test against trunk,
because you can get BCEL snapshots from the Apache Maven Snapshot
repository.
If the CI system is working, the SNAPSHOTs wll be updated regularly
when there have been commits.
If it appears that the snapshot has not been built for some while
since the last commit (e.g. 24 hrs), ask here and someone can prod the
CI system (or just deploy another snapshot).
Of course such builds have no guarantees, and should not be relied on
long-term (they may be replaced at any time), but for test purposes
they will do.
> Niall
>
>
>
>> --S.
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> 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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com> wrote:
> +100 to RERO. +1000 to release before we're all dead. It's been a decade
> people. Just cut a release already. You can always cut another one later.
> Stop with the excuses
>
> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
> users are left in a lurch. Compiling libraries is not a realistic solution.
> As stated previously by others we would also have to patch and compile
> libraries depending on BCEL and also figure the transitive dependency graph
> for everything we use since we can't use Maven to do that due to BCEL not
> being in Maven. This is a huge huge pain because we're big Scala users and
> rely heavily on the Typesafe ecosystem which is dropping support for Java 7
> in all of its products and already has in Play Framework and Akka as well
> as
> others like its Config library.
>
You say "stop with the excuses" and then go on to list a whole bunch of
excuses why its too much effort for you to build BCEL and test it. Yes it
would be an effort - but it would be invaluable to have some pre-release
testing and feedback and help to get it our faster.
Niall
> --S.
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Sarah Murray <sa...@gmail.com>.
Thanks for taking the time to review those patches Mark.
I guarantee you that Mark and Jerome do not know that their patches are
considered difficult to review in a timely manner. The last comment on all
of their patches is from them and they're waiting for a response. If the
issues are considered not clear enough and require more explanation, it
would be helpful to let them and the community know that instead of letting
the issues languish. They seem very willing to do some work to get their
patches in. Let them know what an ideal to review patch looks like and how
there's still a lot of burden on the reviewer in the ones they've submitted.
Mark, Jerome, perhaps you could review each others patches? If you agree to
review each others patches, it could help your patches get in much more
quickly. I know it's not fair I ask you to do more work without doing it
myself, but I'm nowhere near familiar enough with the codebase to be of any
help. Perhaps I could offer my assistance in some other way? I can run
tests on various JVMs, write Java code that doesn't require such complex
knowedge of bytecode, or make a monetary donation to the Apache Foundation
if any of those things would help.
Doing what I can, I just took some time to look at 183
<https://issues.apache.org/jira/browse/BCEL-183>. I guess you're right that
the patch could be split between one patch for field name and one patch for
method name if that seems helpful. Would you want me to open new issues
with the patch split in two for that? Should we check with Jerome and
Emmanuel before doing that? What is it that you're thinking we could do in
terms of a common test framework? I don't see a lot of code duplication or
anything.
--S.
On Fri, Mar 6, 2015 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
> On 06/03/2015 21:05, Sarah Murray wrote:
> > - 187 <https://issues.apache.org/jira/browse/BCEL-187> - has a test
> > case. no committer review for 2 months
>
> Neither has anyone else reviewed it. It isn't just committers that can
> review patches. I've got the necessary commit karma and after looking at
> that issue for a minute or two I can see a whole pile of work that needs
> to be done before I'd even think about committing anything. Just from
> that quick look:
> 1. Review the svn history to see if there are any pointers to which part
> of the JVM spec defines the restriction.
> 2. Review the JVM spec to see if I can see the restriction
> 3. Look at the byte code for the provided example to see which class the
> invoke opcode references. Better yet, write a disabled BCEL unit test to
> show this.
> 4. The structure of the test case looks odd. I suspect it aligns with
> other patches for other issues but nowhere is that explained.
> 5. The class files provided do not have any attached source. Without the
> source code, we have no idea (OK I could fire up a decompiler but that
> is another task) what is actually in those classes.
>
> To put it another way, the current code asserts one behaviour. The bug
> report asserts another. No evidence is provided to support either
> position. Given that most (all?) the current committers likely to work
> on BCEL don't have a deep knowledge of the JVM specs some research is
> required to figure out which is correct. I've set out above how I'd do
> the research. I'm sure there are other, better approaches. Doing the
> research doesn't require commit karma.
>
> > - 188 <https://issues.apache.org/jira/browse/BCEL-188> - has a test
> > case. no committer review for 2 months
>
> Looks to be in better shape than 187 but still no source provided for
> one of the test classes.
>
> > - 183 <https://issues.apache.org/jira/browse/BCEL-183> - has a test
> > case. no committer review for 3 months
>
> It is not at all clear how much of the original issue (if any) was fixed
> by the change reported 19-Dec-2014.
>
> The potential for the required behaviour to vary with class file version
> is a complicating factor.
>
> This issues seems to be bundling up a number of smaller issues. That
> makes it harder to work with even if they are all in the same area.
>
> Generally for all of these issues some pointers to the relevant parts of
> the JVM spec - preferably as comments in the patch - would make it
> easier for folks to review the patches and easier for future maintainers
> to understand what the code is doing.
>
> Also generally, it looks like a number of the patches could be reduced
> in size by pulling out the common testing framework.
>
>
> > The problem is that there's one area where help is really lacking and the
> > community can't contribute there because not everyone has the commit
> access
> > that's needed to get things flowing again.
>
> I disagree with that analysis. There is plenty that could be done to
> move these issues forwards without commit access. I can find the odd
> hour here and there to look at BCEL issues but looking at the three
> issues you quoted above all of them would require far more than an hours
> work to get to a position where I'd be happy to commit something. Pretty
> much all of that work could be done by anyone on this list.
>
> > Perhaps we could add more committers since it's currently a bottleneck?
>
> Committers will be added as and when folks demonstrate the appropriate
> merit.
>
> > E.g. Mark and Jerome both have submitted numerous high quality patches
> and
> > seem to be well-regarded members of the community. Can we give them
> commit
> > access?
>
> I agree they look to be heading in the right direction. I'm not familiar
> enough with the BCEL code base to judge the quality of the patches in
> their current form.
>
> > If we're nervous about maintaining high code quality we can add
> > guidelines such as there must be a test case for any commit and you can't
> > commit your own code - someone else needs to review it.
>
> You really don't want to introduce those sorts of rules if you can help
> it. It would slow progress even further.
>
> > There was talk of an alpha release and it seems like folks are in favor
> of
> > it. Is there anything I can help to do with regards to that?
>
> Right now the most useful thing folks can do is pick a bug that matters
> to them and then work with the community to get the issue to the point
> where a current committer can resolve it with no more than 60 minutes of
> effort.
>
> I can find 60 minutes over the next few days. Which issue do you want to
> fix first?
>
> I'm also more than happy to commit common test code to reduce the
> size/complexity of any proposed patches.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Mark Thomas <ma...@apache.org>.
On 06/03/2015 21:05, Sarah Murray wrote:
> - 187 <https://issues.apache.org/jira/browse/BCEL-187> - has a test
> case. no committer review for 2 months
Neither has anyone else reviewed it. It isn't just committers that can
review patches. I've got the necessary commit karma and after looking at
that issue for a minute or two I can see a whole pile of work that needs
to be done before I'd even think about committing anything. Just from
that quick look:
1. Review the svn history to see if there are any pointers to which part
of the JVM spec defines the restriction.
2. Review the JVM spec to see if I can see the restriction
3. Look at the byte code for the provided example to see which class the
invoke opcode references. Better yet, write a disabled BCEL unit test to
show this.
4. The structure of the test case looks odd. I suspect it aligns with
other patches for other issues but nowhere is that explained.
5. The class files provided do not have any attached source. Without the
source code, we have no idea (OK I could fire up a decompiler but that
is another task) what is actually in those classes.
To put it another way, the current code asserts one behaviour. The bug
report asserts another. No evidence is provided to support either
position. Given that most (all?) the current committers likely to work
on BCEL don't have a deep knowledge of the JVM specs some research is
required to figure out which is correct. I've set out above how I'd do
the research. I'm sure there are other, better approaches. Doing the
research doesn't require commit karma.
> - 188 <https://issues.apache.org/jira/browse/BCEL-188> - has a test
> case. no committer review for 2 months
Looks to be in better shape than 187 but still no source provided for
one of the test classes.
> - 183 <https://issues.apache.org/jira/browse/BCEL-183> - has a test
> case. no committer review for 3 months
It is not at all clear how much of the original issue (if any) was fixed
by the change reported 19-Dec-2014.
The potential for the required behaviour to vary with class file version
is a complicating factor.
This issues seems to be bundling up a number of smaller issues. That
makes it harder to work with even if they are all in the same area.
Generally for all of these issues some pointers to the relevant parts of
the JVM spec - preferably as comments in the patch - would make it
easier for folks to review the patches and easier for future maintainers
to understand what the code is doing.
Also generally, it looks like a number of the patches could be reduced
in size by pulling out the common testing framework.
> The problem is that there's one area where help is really lacking and the
> community can't contribute there because not everyone has the commit access
> that's needed to get things flowing again.
I disagree with that analysis. There is plenty that could be done to
move these issues forwards without commit access. I can find the odd
hour here and there to look at BCEL issues but looking at the three
issues you quoted above all of them would require far more than an hours
work to get to a position where I'd be happy to commit something. Pretty
much all of that work could be done by anyone on this list.
> Perhaps we could add more committers since it's currently a bottleneck?
Committers will be added as and when folks demonstrate the appropriate
merit.
> E.g. Mark and Jerome both have submitted numerous high quality patches and
> seem to be well-regarded members of the community. Can we give them commit
> access?
I agree they look to be heading in the right direction. I'm not familiar
enough with the BCEL code base to judge the quality of the patches in
their current form.
> If we're nervous about maintaining high code quality we can add
> guidelines such as there must be a test case for any commit and you can't
> commit your own code - someone else needs to review it.
You really don't want to introduce those sorts of rules if you can help
it. It would slow progress even further.
> There was talk of an alpha release and it seems like folks are in favor of
> it. Is there anything I can help to do with regards to that?
Right now the most useful thing folks can do is pick a bug that matters
to them and then work with the community to get the issue to the point
where a current committer can resolve it with no more than 60 minutes of
effort.
I can find 60 minutes over the next few days. Which issue do you want to
fix first?
I'm also more than happy to commit common test code to reduce the
size/complexity of any proposed patches.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Sarah Murray <sa...@gmail.com>.
Sorry for the frustration I expressed. It was probably not the most
constructive way to voice my opinion.
A well described bug with a patch and a test case tends to get committed very
> quickly.
I'm not sure you've looked at the issue tracker lately. This really isn't
true as far as I can see, which is the cause of my exasperation. We're
blocking on a release until issues are resolved. But no one with commit
access is accepting changes, so we've just stalled out.
If you think some of the BCEL bugs are in this state and being over looked
> feel free to add a "What else is needed to get this committed?" question
> on the bug.
I'm happy to do this, but I think it'd be more annoying than helpful. Most
BCEL bugs I've seen are in this state. Putting the same comment on every
bug doesn't seem helpful. Of the four issues marked to 6.0, three of them
are stalled on having someone review and commit the patches:
- 187 <https://issues.apache.org/jira/browse/BCEL-187> - has a test
case. no committer review for 2 months
- 188 <https://issues.apache.org/jira/browse/BCEL-188> - has a test
case. no committer review for 2 months
- 183 <https://issues.apache.org/jira/browse/BCEL-183> - has a test
case. no committer review for 3 months
We don't have suppliers and customers at the ASF. We have a community. Everyone
> has a part to play.
The problem is that there's one area where help is really lacking and the
community can't contribute there because not everyone has the commit access
that's needed to get things flowing again. Perhaps we could add more
committers since it's currently a bottleneck? I've seen that work really
well when other projects either start to get overwhelmed or fizzle out.
E.g. Mark and Jerome both have submitted numerous high quality patches and
seem to be well-regarded members of the community. Can we give them commit
access? If we're nervous about maintaining high code quality we can add
guidelines such as there must be a test case for any commit and you can't
commit your own code - someone else needs to review it.
There was talk of an alpha release and it seems like folks are in favor of
it. Is there anything I can help to do with regards to that?
--S.
On Fri, Mar 6, 2015 at 12:10 PM, Mark Thomas <ma...@apache.org> wrote:
> All,
>
> This is a community of volunteers. If you want to see something happen,
> demanding that other people do something is not the way to achieve your
> aims. At best your demands will have no impact. At worst, they will
> irritate folks that might have otherwise done the very thing you want to
> see happen.
>
> If you want to see a BCEL release then the best thing you can do is
> pitch in and help. Jira shows 49 open BCEL issues 4 of which are tagged
> for 6.0.
>
> Take a look at those 4 issues. What needs to be done to resolve them? Is
> a patch required? Is a review required? Would a test case that
> demonstrates the issue help (answer "yes!" unless one already exists).
>
> A well described bug with a patch and a test case tends to get committed
> very quickly. If you think some of the BCEL bugs are in this state and
> being over looked feel free to add a "What else is needed to get this
> committed?" question on the bug.
>
> Of the other 45 issues which ones need to be fixed in 6.0? 6.x? 7.0? I'd
> me amazed if all of those 45 were valid. Which ones can be closed? If
> you need versions created in Jira, ask. If you need more karma to assign
> issues to versions, ask. If you aren't sure what criteria should be used
> to decide which version to assign issues to, ask. Better still propose
> some criteria to start the discussion.
>
> We don't have suppliers and customers at the ASF. We have a community.
> Everyone has a part to play.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Mark Thomas <ma...@apache.org>.
All,
This is a community of volunteers. If you want to see something happen,
demanding that other people do something is not the way to achieve your
aims. At best your demands will have no impact. At worst, they will
irritate folks that might have otherwise done the very thing you want to
see happen.
If you want to see a BCEL release then the best thing you can do is
pitch in and help. Jira shows 49 open BCEL issues 4 of which are tagged
for 6.0.
Take a look at those 4 issues. What needs to be done to resolve them? Is
a patch required? Is a review required? Would a test case that
demonstrates the issue help (answer "yes!" unless one already exists).
A well described bug with a patch and a test case tends to get committed
very quickly. If you think some of the BCEL bugs are in this state and
being over looked feel free to add a "What else is needed to get this
committed?" question on the bug.
Of the other 45 issues which ones need to be fixed in 6.0? 6.x? 7.0? I'd
me amazed if all of those 45 were valid. Which ones can be closed? If
you need versions created in Jira, ask. If you need more karma to assign
issues to versions, ask. If you aren't sure what criteria should be used
to decide which version to assign issues to, ask. Better still propose
some criteria to start the discussion.
We don't have suppliers and customers at the ASF. We have a community.
Everyone has a part to play.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sarahkm1972 <sa...@gmail.com>.
+100 to RERO. +1000 to release before we're all dead. It's been a decade
people. Just cut a release already. You can always cut another one later.
Stop with the excuses
Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
users are left in a lurch. Compiling libraries is not a realistic solution.
As stated previously by others we would also have to patch and compile
libraries depending on BCEL and also figure the transitive dependency graph
for everything we use since we can't use Maven to do that due to BCEL not
being in Maven. This is a huge huge pain because we're big Scala users and
rely heavily on the Typesafe ecosystem which is dropping support for Java 7
in all of its products and already has in Play Framework and Akka as well as
others like its Config library.
--S.
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ian McAllister <ia...@gmail.com>.
Do you have ideas for when an alpha release will be pushed to Maven?
ian
On Thu, Mar 5, 2015 at 11:09 AM, Ben McCann <be...@benmccann.com> wrote:
> I'd much rather an imperfect version of BCEL be released than we continue
> to wait for perfection and never release. I'm very concerned that we're
> going to be waiting at least a year for the 6.0 release. Mark submitted
> about a dozen issues around six weeks ago and probably only one or two have
> been closed. At the current rate it will be a year before they're all
> addressed. And who's to say that no new issues will be filed in the next
> year pushing the release ever further out?
>
> We could easily release 6.0 now, which we've been on the verge of doing.
> There were 3 RCs for it and it's been 7 months since voting on the first
> RC. In a year when all of Mark's issues are addressed we can release 7.0.
> Changing package names again in another year doesn't seem so bad. It's an
> easy sed script to update your code to a new package name. If we don't cut
> a release then no released version of BCEL will work with any supported
> version of Java.
>
> -Ben
>
>
>
> On Wed, Mar 4, 2015 at 10:13 AM, Ian McAllister <ia...@gmail.com>
> wrote:
>
> > quick follow up on this... were you by chance able to create an alpha
> > release yet? very much looking forward to having the code in maven!!
> >
> > ian
> >
> > On Mon, Mar 2, 2015 at 3:11 PM, ianmca86 <ia...@gmail.com> wrote:
> >
> > > yes, that would be perfect! (agreed it would have to go to maven)
> > >
> > > thanks so much for taking the suggestion into consideration!
> > >
> > > -ian
> > >
> > >
> > > On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
> > > ml-node+s680414n4673398h70@n4.nabble.com> wrote:
> > >
> > > > Le 03/03/2015 00:03, Gary Gregory a écrit :
> > > > > We could release an Alpha to make it clear that we are still
> working
> > on
> > > > > possibly important changes.
> > > >
> > > > But we would have to upload it to Maven Central to make it really
> > > > useful. If there is a consensus to do that I'm ok to cut a release
> > soon.
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> > > > For additional commands, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
> > > >
> > > >
> > > >
> > > > ------------------------------
> > > > If you reply to this email, your message will be added to the
> > discussion
> > > > below:
> > > >
> > > >
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> > > > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > > > <
> > >
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> > > >
> > > > .
> > > > NAML
> > > > <
> > >
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
> > > Sent from the Commons - Dev mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> about.me/benmccann
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
I'd much rather an imperfect version of BCEL be released than we continue
to wait for perfection and never release. I'm very concerned that we're
going to be waiting at least a year for the 6.0 release. Mark submitted
about a dozen issues around six weeks ago and probably only one or two have
been closed. At the current rate it will be a year before they're all
addressed. And who's to say that no new issues will be filed in the next
year pushing the release ever further out?
We could easily release 6.0 now, which we've been on the verge of doing.
There were 3 RCs for it and it's been 7 months since voting on the first
RC. In a year when all of Mark's issues are addressed we can release 7.0.
Changing package names again in another year doesn't seem so bad. It's an
easy sed script to update your code to a new package name. If we don't cut
a release then no released version of BCEL will work with any supported
version of Java.
-Ben
On Wed, Mar 4, 2015 at 10:13 AM, Ian McAllister <ia...@gmail.com> wrote:
> quick follow up on this... were you by chance able to create an alpha
> release yet? very much looking forward to having the code in maven!!
>
> ian
>
> On Mon, Mar 2, 2015 at 3:11 PM, ianmca86 <ia...@gmail.com> wrote:
>
> > yes, that would be perfect! (agreed it would have to go to maven)
> >
> > thanks so much for taking the suggestion into consideration!
> >
> > -ian
> >
> >
> > On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
> > ml-node+s680414n4673398h70@n4.nabble.com> wrote:
> >
> > > Le 03/03/2015 00:03, Gary Gregory a écrit :
> > > > We could release an Alpha to make it clear that we are still working
> on
> > > > possibly important changes.
> > >
> > > But we would have to upload it to Maven Central to make it really
> > > useful. If there is a consensus to do that I'm ok to cut a release
> soon.
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
> > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> > > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> > >
> > > .
> > > NAML
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
> > Sent from the Commons - Dev mailing list archive at Nabble.com.
> >
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ian McAllister <ia...@gmail.com>.
quick follow up on this... were you by chance able to create an alpha
release yet? very much looking forward to having the code in maven!!
ian
On Mon, Mar 2, 2015 at 3:11 PM, ianmca86 <ia...@gmail.com> wrote:
> yes, that would be perfect! (agreed it would have to go to maven)
>
> thanks so much for taking the suggestion into consideration!
>
> -ian
>
>
> On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
> ml-node+s680414n4673398h70@n4.nabble.com> wrote:
>
> > Le 03/03/2015 00:03, Gary Gregory a écrit :
> > > We could release an Alpha to make it clear that we are still working on
> > > possibly important changes.
> >
> > But we would have to upload it to Maven Central to make it really
> > useful. If there is a consensus to do that I'm ok to cut a release soon.
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
> >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> >
> > .
> > NAML
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by ianmca86 <ia...@gmail.com>.
yes, that would be perfect! (agreed it would have to go to maven)
thanks so much for taking the suggestion into consideration!
-ian
On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
ml-node+s680414n4673398h70@n4.nabble.com> wrote:
> Le 03/03/2015 00:03, Gary Gregory a écrit :
> > We could release an Alpha to make it clear that we are still working on
> > possibly important changes.
>
> But we would have to upload it to Maven Central to make it really
> useful. If there is a consensus to do that I'm ok to cut a release soon.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy>
> .
> NAML
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 03/03/2015 00:03, Gary Gregory a écrit :
> We could release an Alpha to make it clear that we are still working on
> possibly important changes.
But we would have to upload it to Maven Central to make it really
useful. If there is a consensus to do that I'm ok to cut a release soon.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
+1 to releasing an Alpha or making 6.0-RC3 available via Maven. Compiling
it ourselves is a really painful solution. It means we also need to setup
our own public Maven repository or make other drastic changes to our
release engineering.
On Mon, Mar 2, 2015 at 3:03 PM, Gary Gregory <ga...@gmail.com> wrote:
> We could release an Alpha to make it clear that we are still working on
> possibly important changes.
>
> G
>
> On Mon, Mar 2, 2015 at 2:46 PM, ianmca86 <ia...@gmail.com> wrote:
>
> > Perhaps we could at least get a milestone release (i.e. pre-RC)? I'd
> like
> > to see if I can submit a branch to jibx where I get them to use the
> latest
> > bcel code. jibx won't work with Java 8 because we're waiting on a bcel
> > release. It's hard to work on making jibx compatible with Java 8 as long
> as
> > we're blocked on bcel, but if there were a milestone or rc release that
> > would allow us to get some work done towards this goal and also help test
> > the past nine years of changes to unearth any possible bcel problems
> >
> > On Mon, Mar 2, 2015 at 2:37 PM, Emmanuel Bourg-3 [via Apache Commons] <
> > ml-node+s680414n4673392h84@n4.nabble.com> wrote:
> >
> > > Le 02/03/2015 22:33, Gary Gregory a écrit :
> > > > I'm all for RERO if the release manager is willing.
> > >
> > > I tend to agree with RERO, but if the API is not ready I don't think
> > > it's right to rush into a release, and the deeper I dig into BCEL the
> > > more I'm bothered by the issues I find.
> > >
> > > Once BCEL is back in shape it'll be easier to release often.
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673392&i=0>
> > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673392&i=1>
> > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673392.html
> > > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> > >
> > > .
> > > NAML
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673393.html
> > Sent from the Commons - Dev mailing list archive at Nabble.com.
>
>
>
>
> --
> 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
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
We could release an Alpha to make it clear that we are still working on
possibly important changes.
G
On Mon, Mar 2, 2015 at 2:46 PM, ianmca86 <ia...@gmail.com> wrote:
> Perhaps we could at least get a milestone release (i.e. pre-RC)? I'd like
> to see if I can submit a branch to jibx where I get them to use the latest
> bcel code. jibx won't work with Java 8 because we're waiting on a bcel
> release. It's hard to work on making jibx compatible with Java 8 as long as
> we're blocked on bcel, but if there were a milestone or rc release that
> would allow us to get some work done towards this goal and also help test
> the past nine years of changes to unearth any possible bcel problems
>
> On Mon, Mar 2, 2015 at 2:37 PM, Emmanuel Bourg-3 [via Apache Commons] <
> ml-node+s680414n4673392h84@n4.nabble.com> wrote:
>
> > Le 02/03/2015 22:33, Gary Gregory a écrit :
> > > I'm all for RERO if the release manager is willing.
> >
> > I tend to agree with RERO, but if the API is not ready I don't think
> > it's right to rush into a release, and the deeper I dig into BCEL the
> > more I'm bothered by the issues I find.
> >
> > Once BCEL is back in shape it'll be easier to release often.
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673392&i=0>
> > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673392&i=1>
> >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673392.html
> > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> >
> > .
> > NAML
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673393.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by ianmca86 <ia...@gmail.com>.
Perhaps we could at least get a milestone release (i.e. pre-RC)? I'd like
to see if I can submit a branch to jibx where I get them to use the latest
bcel code. jibx won't work with Java 8 because we're waiting on a bcel
release. It's hard to work on making jibx compatible with Java 8 as long as
we're blocked on bcel, but if there were a milestone or rc release that
would allow us to get some work done towards this goal and also help test
the past nine years of changes to unearth any possible bcel problems
On Mon, Mar 2, 2015 at 2:37 PM, Emmanuel Bourg-3 [via Apache Commons] <
ml-node+s680414n4673392h84@n4.nabble.com> wrote:
> Le 02/03/2015 22:33, Gary Gregory a écrit :
> > I'm all for RERO if the release manager is willing.
>
> I tend to agree with RERO, but if the API is not ready I don't think
> it's right to rush into a release, and the deeper I dig into BCEL the
> more I'm bothered by the issues I find.
>
> Once BCEL is back in shape it'll be easier to release often.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673392&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673392&i=1>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673392.html
> To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy>
> .
> NAML
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673393.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 2, 2015 at 2:44 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 02/03/2015 22:33, Gary Gregory a écrit :
> > I'm all for RERO if the release manager is willing.
>
> I tend to agree with RERO, but if the API is not ready I don't think
> it's right to rush into a release, and the deeper I dig into BCEL the
> more I'm bothered by the issues I find.
>
> Once BCEL is back in shape it'll be easier to release often.
>
I, for one, am grateful you are keeping a close eye on this. Thank you!
Gary
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 02/03/2015 22:33, Gary Gregory a écrit :
> I'm all for RERO if the release manager is willing.
I tend to agree with RERO, but if the API is not ready I don't think
it's right to rush into a release, and the deeper I dig into BCEL the
more I'm bothered by the issues I find.
Once BCEL is back in shape it'll be easier to release often.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 2, 2015 at 2:07 PM, sebb <se...@gmail.com> wrote:
> On 2 March 2015 at 21:33, Gary Gregory <ga...@gmail.com> wrote:
> > I'm all for RERO if the release manager is willing.
>
> RM willingness is only part of it.
>
> RERO is all very well if:
> - the API is stable; or
> - frequent changes of package name/Maven coords are acceptable to
> consumers; or
> - one does not care about binary compatibilty
>
> IMO it's unhelpful to keep pushing the RERO mantra in isolation.
>
Yes, agreed. I was assuming we all see eye to eye on the semantics.
Gary
>
> > Gary
> >
> > On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <ia...@gmail.com> wrote:
> >
> >> +1
> >>
> >> no one has really answered ben's question yet. if bcel 209
> >> <https://issues.apache.org/jira/browse/BCEL-209> is committed could
> we
> >> cut
> >> a release? it seems like everyone is okay with the general approach
> taken
> >> there
> >>
> >> my company also is mandating all projects move to java 8 this month
> since
> >> java 7 is discontinued next month. i'm quite nervous that patch has been
> >> outstanding for a month already and we're blocking on it. nine years is
> too
> >> long between releases and we don't need to drag this out more
> >>
> >> regards
> >> ian
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > 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
>
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 2 March 2015 at 21:33, Gary Gregory <ga...@gmail.com> wrote:
> I'm all for RERO if the release manager is willing.
RM willingness is only part of it.
RERO is all very well if:
- the API is stable; or
- frequent changes of package name/Maven coords are acceptable to consumers; or
- one does not care about binary compatibilty
IMO it's unhelpful to keep pushing the RERO mantra in isolation.
> Gary
>
> On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <ia...@gmail.com> wrote:
>
>> +1
>>
>> no one has really answered ben's question yet. if bcel 209
>> <https://issues.apache.org/jira/browse/BCEL-209> is committed could we
>> cut
>> a release? it seems like everyone is okay with the general approach taken
>> there
>>
>> my company also is mandating all projects move to java 8 this month since
>> java 7 is discontinued next month. i'm quite nervous that patch has been
>> outstanding for a month already and we're blocking on it. nine years is too
>> long between releases and we don't need to drag this out more
>>
>> regards
>> ian
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> 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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
I'm all for RERO if the release manager is willing.
Gary
On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <ia...@gmail.com> wrote:
> +1
>
> no one has really answered ben's question yet. if bcel 209
> <https://issues.apache.org/jira/browse/BCEL-209> is committed could we
> cut
> a release? it seems like everyone is okay with the general approach taken
> there
>
> my company also is mandating all projects move to java 8 this month since
> java 7 is discontinued next month. i'm quite nervous that patch has been
> outstanding for a month already and we're blocking on it. nine years is too
> long between releases and we don't need to drag this out more
>
> regards
> ian
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by ianmca86 <ia...@gmail.com>.
+1
no one has really answered ben's question yet. if bcel 209
<https://issues.apache.org/jira/browse/BCEL-209> is committed could we cut
a release? it seems like everyone is okay with the general approach taken
there
my company also is mandating all projects move to java 8 this month since
java 7 is discontinued next month. i'm quite nervous that patch has been
outstanding for a month already and we're blocking on it. nine years is too
long between releases and we don't need to drag this out more
regards
ian
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 19 February 2015 at 17:13, Stian Soiland-Reyes <st...@apache.org> wrote:
> That sounds more like a political release number, I would hope we were
> not too political here (except about Apache values :) )
Not necessarily, my example was about requiring a major bump in JVM version.
Still binary compatible, but might require users to upgrade their host JVM.
Therefore it may be worth flagging the change to end-users via the
version number.
> Changing the major version number should cause Maven/OSGi t
o moan if
> project A needs say bcel 5.1 and another tries to pull in 6.0 - that
> would be the purpose of the major version number change.
AFAIK Maven does not do that.
OSGi may do so; I don't know.
> If there is no binary incompatibility introduced, then it seems
> pointless to enforce such warnings with a new major version in pom.xml
> and friends.
What is the evidence that a major bump causes warnings?
> The nature of the project matters - say an application which is not
> dependended on as a library would be more natural to bump the major
> version when there are significant UI or feature changes.
Yes, and such projects don't really need to pay much attention to
binary compatibility either.
>
> (This is a very relevant discussion as another thread was just talking
> about updating https://commons.apache.org/releases/versioning.html to
> relate to SemVer)
>
>
> On 19 February 2015 at 15:38, Emmanuel Bourg <eb...@apache.org> wrote:
>> Le 19/02/2015 16:29, sebb a écrit :
>>
>>> However, according to SemVer one should bump major version if and only
>>> if breaking compat.
>>> It's only recently that Commons has started discussing whether to use
>>> strict SemVer or not; I don't think it has been agreed for all
>>> components.
>>
>> SemVer provides sane guidelines but I wouldn't follow it religiously. In
>> my opinion a major version bump is ok even if the compatibility is
>> preserved, it can denote major improvements like the ones staged for
>> BCEL 6.0.
+1
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating)
> http://orcid.org/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Stian Soiland-Reyes <st...@apache.org>.
That sounds more like a political release number, I would hope we were
not too political here (except about Apache values :) )
Changing the major version number should cause Maven/OSGi to moan if
project A needs say bcel 5.1 and another tries to pull in 6.0 - that
would be the purpose of the major version number change.
If there is no binary incompatibility introduced, then it seems
pointless to enforce such warnings with a new major version in pom.xml
and friends.
The nature of the project matters - say an application which is not
dependended on as a library would be more natural to bump the major
version when there are significant UI or feature changes.
(This is a very relevant discussion as another thread was just talking
about updating https://commons.apache.org/releases/versioning.html to
relate to SemVer)
On 19 February 2015 at 15:38, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 19/02/2015 16:29, sebb a écrit :
>
>> However, according to SemVer one should bump major version if and only
>> if breaking compat.
>> It's only recently that Commons has started discussing whether to use
>> strict SemVer or not; I don't think it has been agreed for all
>> components.
>
> SemVer provides sane guidelines but I wouldn't follow it religiously. In
> my opinion a major version bump is ok even if the compatibility is
> preserved, it can denote major improvements like the ones staged for
> BCEL 6.0.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 19/02/2015 16:29, sebb a écrit :
> However, according to SemVer one should bump major version if and only
> if breaking compat.
> It's only recently that Commons has started discussing whether to use
> strict SemVer or not; I don't think it has been agreed for all
> components.
SemVer provides sane guidelines but I wouldn't follow it religiously. In
my opinion a major version bump is ok even if the compatibility is
preserved, it can denote major improvements like the ones staged for
BCEL 6.0.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 19 February 2015 at 15:19, Benedikt Ritter <br...@apache.org> wrote:
> 2015-02-19 16:14 GMT+01:00 Ben McCann <be...@benmccann.com>:
>
>> Why do you say users would have to rename all their import statements? Is
>> there a patch pending that we're consider which would change the package
>> name? I don't think there'd be any changes that be hard for end users to
>> deal with that I'm aware of.
>>
>
> Changing the major version number for a commons component always implies
> changing maven coords and the package name. We do this, so that several
> versions of the same commons component can be in the same classpath.
That's cart before horse.
The major version number change is not the driver here.
If a release breaks binary compatibility then the major version must
change and so must the package/Maven coords.
It's perfectly possible to bump the major version number and not
change package name / Maven coords provided that the release is still
binary compatible.
However, according to SemVer one should bump major version if and only
if breaking compat.
It's only recently that Commons has started discussing whether to use
strict SemVer or not; I don't think it has been agreed for all
components.
For example, one might want to have a major version bump if the Java
version requirements changed from say 1.4 to 1.8, even though it was
still binary compat.
> Benedikt
>
>
>>
>> On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter <br...@apache.org>
>> wrote:
>>
>> > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
>> >
>> > > Le 19/02/2015 15:17, Ben McCann a écrit :
>> > > > Perhaps if there are only a few breaking changes we could prioritize
>> > > > reviewing those first and leave the rest for 6.1. Alternatively, we
>> > > could
>> > > > release what's available now as 6.0 and release all the patches in a
>> > > couple
>> > > > months as 7.0.
>> > >
>> > > I wouldn't force our users to rename all their import statements in a
>> > > couple of month as we release BCEL 7.0 with breaking changes because we
>> > > didn't want to handle a known issue for BCEL 6.0.
>> > >
>> > > Let's settle this now.
>> > >
>> >
>> > +1
>> >
>> >
>> > >
>> > > Emmanuel Bourg
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > http://people.apache.org/~britter/
>> > http://www.systemoutprintln.de/
>> > http://twitter.com/BenediktRitter
>> > http://github.com/britter
>> >
>>
>>
>>
>> --
>> about.me/benmccann
>>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
Is BCEL-209 the only pending issue that would break binary compatibility?
Perhaps we could prioritize the issues that would break compatibility.
On Thu, Feb 19, 2015 at 7:19 AM, Benedikt Ritter <br...@apache.org> wrote:
> 2015-02-19 16:14 GMT+01:00 Ben McCann <be...@benmccann.com>:
>
> > Why do you say users would have to rename all their import statements?
Is
> > there a patch pending that we're consider which would change the package
> > name? I don't think there'd be any changes that be hard for end users to
> > deal with that I'm aware of.
> >
>
> Changing the major version number for a commons component always implies
> changing maven coords and the package name.
No, it does not. We can release a new major version without a new package
name and new maven coords IFF the new version is binary compatible.
Gary
> We do this, so that several
> versions of the same commons component can be in the same classpath.
>
> Benedikt
>
>
> >
> > On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> > > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
> > >
> > > > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > > > Perhaps if there are only a few breaking changes we could
> prioritize
> > > > > reviewing those first and leave the rest for 6.1. Alternatively,
> we
> > > > could
> > > > > release what's available now as 6.0 and release all the patches in
> a
> > > > couple
> > > > > months as 7.0.
> > > >
> > > > I wouldn't force our users to rename all their import statements in
a
> > > > couple of month as we release BCEL 7.0 with breaking changes because
> we
> > > > didn't want to handle a known issue for BCEL 6.0.
> > > >
> > > > Let's settle this now.
> > > >
> > >
> > > +1
> > >
> > >
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
> >
> >
> > --
> > about.me/benmccann
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Feb 19, 2015 at 7:19 AM, Benedikt Ritter <br...@apache.org> wrote:
> 2015-02-19 16:14 GMT+01:00 Ben McCann <be...@benmccann.com>:
>
> > Why do you say users would have to rename all their import statements? Is
> > there a patch pending that we're consider which would change the package
> > name? I don't think there'd be any changes that be hard for end users to
> > deal with that I'm aware of.
> >
>
> Changing the major version number for a commons component always implies
> changing maven coords and the package name.
No, it does not. We can release a new major version without a new package
name and new maven coords IFF the new version is binary compatible.
Gary
> We do this, so that several
> versions of the same commons component can be in the same classpath.
>
> Benedikt
>
>
> >
> > On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> > > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
> > >
> > > > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > > > Perhaps if there are only a few breaking changes we could
> prioritize
> > > > > reviewing those first and leave the rest for 6.1. Alternatively,
> we
> > > > could
> > > > > release what's available now as 6.0 and release all the patches in
> a
> > > > couple
> > > > > months as 7.0.
> > > >
> > > > I wouldn't force our users to rename all their import statements in a
> > > > couple of month as we release BCEL 7.0 with breaking changes because
> we
> > > > didn't want to handle a known issue for BCEL 6.0.
> > > >
> > > > Let's settle this now.
> > > >
> > >
> > > +1
> > >
> > >
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
> >
> >
> > --
> > about.me/benmccann
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Benedikt Ritter <br...@apache.org>.
2015-02-19 16:14 GMT+01:00 Ben McCann <be...@benmccann.com>:
> Why do you say users would have to rename all their import statements? Is
> there a patch pending that we're consider which would change the package
> name? I don't think there'd be any changes that be hard for end users to
> deal with that I'm aware of.
>
Changing the major version number for a commons component always implies
changing maven coords and the package name. We do this, so that several
versions of the same commons component can be in the same classpath.
Benedikt
>
> On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter <br...@apache.org>
> wrote:
>
> > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
> >
> > > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > > Perhaps if there are only a few breaking changes we could prioritize
> > > > reviewing those first and leave the rest for 6.1. Alternatively, we
> > > could
> > > > release what's available now as 6.0 and release all the patches in a
> > > couple
> > > > months as 7.0.
> > >
> > > I wouldn't force our users to rename all their import statements in a
> > > couple of month as we release BCEL 7.0 with breaking changes because we
> > > didn't want to handle a known issue for BCEL 6.0.
> > >
> > > Let's settle this now.
> > >
> >
> > +1
> >
> >
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> about.me/benmccann
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
Why do you say users would have to rename all their import statements? Is
there a patch pending that we're consider which would change the package
name? I don't think there'd be any changes that be hard for end users to
deal with that I'm aware of.
On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter <br...@apache.org> wrote:
> 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
>
> > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > Perhaps if there are only a few breaking changes we could prioritize
> > > reviewing those first and leave the rest for 6.1. Alternatively, we
> > could
> > > release what's available now as 6.0 and release all the patches in a
> > couple
> > > months as 7.0.
> >
> > I wouldn't force our users to rename all their import statements in a
> > couple of month as we release BCEL 7.0 with breaking changes because we
> > didn't want to handle a known issue for BCEL 6.0.
> >
> > Let's settle this now.
> >
>
> +1
>
>
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Benedikt Ritter <br...@apache.org>.
2015-02-19 16:06 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
> Le 19/02/2015 15:17, Ben McCann a écrit :
> > Perhaps if there are only a few breaking changes we could prioritize
> > reviewing those first and leave the rest for 6.1. Alternatively, we
> could
> > release what's available now as 6.0 and release all the patches in a
> couple
> > months as 7.0.
>
> I wouldn't force our users to rename all their import statements in a
> couple of month as we release BCEL 7.0 with breaking changes because we
> didn't want to handle a known issue for BCEL 6.0.
>
> Let's settle this now.
>
+1
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 19/02/2015 15:17, Ben McCann a écrit :
> Perhaps if there are only a few breaking changes we could prioritize
> reviewing those first and leave the rest for 6.1. Alternatively, we could
> release what's available now as 6.0 and release all the patches in a couple
> months as 7.0.
I wouldn't force our users to rename all their import statements in a
couple of month as we release BCEL 7.0 with breaking changes because we
didn't want to handle a known issue for BCEL 6.0.
Let's settle this now.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
Perhaps if there are only a few breaking changes we could prioritize
reviewing those first and leave the rest for 6.1. Alternatively, we could
release what's available now as 6.0 and release all the patches in a couple
months as 7.0.
On Thu, Feb 19, 2015 at 6:09 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 19/02/2015 14:59, Ben McCann a écrit :
>
> > Mark, do any of your pending changes break binary compatibility? If so,
> do
> > you mind sharing which do and which don't. It could be nice to release a
> > 6.0 now and then release a 6.1 with your changes and any bug fixes for
> > issues discovered in 6.0
>
> There are breaking changes like BCEL-209 that must be addressed now.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 19/02/2015 14:59, Ben McCann a écrit :
> Mark, do any of your pending changes break binary compatibility? If so, do
> you mind sharing which do and which don't. It could be nice to release a
> 6.0 now and then release a 6.1 with your changes and any bug fixes for
> issues discovered in 6.0
There are breaking changes like BCEL-209 that must be addressed now.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
+mark
Mark, do any of your pending changes break binary compatibility? If so, do
you mind sharing which do and which don't. It could be nice to release a
6.0 now and then release a 6.1 with your changes and any bug fixes for
issues discovered in 6.0
Thanks,
Ben
On Wed, Feb 18, 2015 at 10:45 PM, Benedikt Ritter <br...@apache.org>
wrote:
> 2015-02-19 5:11 GMT+01:00 Gary Gregory <ga...@gmail.com>:
>
> > On Wed, Feb 18, 2015 at 7:04 PM, Ben McCann <be...@benmccann.com> wrote:
> >
> > > Would it be possible to release 6.0 now and release Mark's patches as
> 6.1
> > > or 7.0? I'm concerned it may be quite a long time before his patches
> are
> > > committed since they are not actively being reviewed and there is no
> > > activity on them for the past couple weeks.
> > >
> > > There is little downside to frequent releases in my experience.
> > Infrequent
> > > releases on the other hand can be a source of frustration as it means
> it
> > > can be quite difficult to use the code that has been committed.
> >
> >
> > +1
> >
>
> If those changes don't imply breaking binary compatibility we can include
> them in 6.1.
>
>
> >
> > Gary
> >
> >
> > > This is the
> > > exact reason the node.js community was splintered and the io.js fork
> was
> > > created. While end users can easily build from source it can become
> > > extremely difficult when there are multiple transitive dependencies
> > relying
> > > on the library. Users end up having to maintain patched versions not
> only
> > > of BCEL but of the libraries that depend on BCEL which means there can
> be
> > > quite a bit of overhead. As the length of time between releases grows
> the
> > > number of custom patches each user has to separately maintain in each
> > > library depending on BCEL grows. Right now it has been nine years.
> > >
> > > Thanks,
> > > Ben
> > > On Feb 10, 2015 1:53 AM, "Ben McCann" <be...@benmccann.com> wrote:
> > >
> > > > Great, thanks for the update!
> > > >
> > > > Btw, for those not familiar with which issues those are, here's a
> list
> > of
> > > > the ones Mark raised that are not yet resolved:
> > > > https://issues.apache.org/jira/browse/BCEL-79
> > > > https://issues.apache.org/jira/browse/BCEL-195
> > > > https://issues.apache.org/jira/browse/BCEL-196
> > > > https://issues.apache.org/jira/browse/BCEL-197
> > > > https://issues.apache.org/jira/browse/BCEL-198
> > > > https://issues.apache.org/jira/browse/BCEL-199
> > > > https://issues.apache.org/jira/browse/BCEL-200
> > > > https://issues.apache.org/jira/browse/BCEL-201
> > > > https://issues.apache.org/jira/browse/BCEL-202
> > > > https://issues.apache.org/jira/browse/BCEL-205
> > > > https://issues.apache.org/jira/browse/BCEL-206
> > > > https://issues.apache.org/jira/browse/BCEL-208
> > > > https://issues.apache.org/jira/browse/BCEL-209
> > > >
> > > > Thanks!
> > > > -Ben
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Feb 8, 2015 at 11:32 PM, Emmanuel Bourg <eb...@apache.org>
> > > wrote:
> > > >
> > > >> Le 09/02/2015 06:29, chengas123 a écrit :
> > > >>
> > > >> > BCEL really needs the 6.0 release to be cut or it will no longer
> be
> > > >> > compatible with any supported version of Java. Would anyone be
> able
> > to
> > > >> cut a
> > > >> > new release?
> > > >>
> > > >> I will once the issues raised by Marks Roberts are addressed.
> > > >>
> > > >> Emmanuel Bourg
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > about.me/benmccann
> > > >
> > >
> >
> >
> >
> > --
> > 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
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Benedikt Ritter <br...@apache.org>.
2015-02-19 5:11 GMT+01:00 Gary Gregory <ga...@gmail.com>:
> On Wed, Feb 18, 2015 at 7:04 PM, Ben McCann <be...@benmccann.com> wrote:
>
> > Would it be possible to release 6.0 now and release Mark's patches as 6.1
> > or 7.0? I'm concerned it may be quite a long time before his patches are
> > committed since they are not actively being reviewed and there is no
> > activity on them for the past couple weeks.
> >
> > There is little downside to frequent releases in my experience.
> Infrequent
> > releases on the other hand can be a source of frustration as it means it
> > can be quite difficult to use the code that has been committed.
>
>
> +1
>
If those changes don't imply breaking binary compatibility we can include
them in 6.1.
>
> Gary
>
>
> > This is the
> > exact reason the node.js community was splintered and the io.js fork was
> > created. While end users can easily build from source it can become
> > extremely difficult when there are multiple transitive dependencies
> relying
> > on the library. Users end up having to maintain patched versions not only
> > of BCEL but of the libraries that depend on BCEL which means there can be
> > quite a bit of overhead. As the length of time between releases grows the
> > number of custom patches each user has to separately maintain in each
> > library depending on BCEL grows. Right now it has been nine years.
> >
> > Thanks,
> > Ben
> > On Feb 10, 2015 1:53 AM, "Ben McCann" <be...@benmccann.com> wrote:
> >
> > > Great, thanks for the update!
> > >
> > > Btw, for those not familiar with which issues those are, here's a list
> of
> > > the ones Mark raised that are not yet resolved:
> > > https://issues.apache.org/jira/browse/BCEL-79
> > > https://issues.apache.org/jira/browse/BCEL-195
> > > https://issues.apache.org/jira/browse/BCEL-196
> > > https://issues.apache.org/jira/browse/BCEL-197
> > > https://issues.apache.org/jira/browse/BCEL-198
> > > https://issues.apache.org/jira/browse/BCEL-199
> > > https://issues.apache.org/jira/browse/BCEL-200
> > > https://issues.apache.org/jira/browse/BCEL-201
> > > https://issues.apache.org/jira/browse/BCEL-202
> > > https://issues.apache.org/jira/browse/BCEL-205
> > > https://issues.apache.org/jira/browse/BCEL-206
> > > https://issues.apache.org/jira/browse/BCEL-208
> > > https://issues.apache.org/jira/browse/BCEL-209
> > >
> > > Thanks!
> > > -Ben
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Feb 8, 2015 at 11:32 PM, Emmanuel Bourg <eb...@apache.org>
> > wrote:
> > >
> > >> Le 09/02/2015 06:29, chengas123 a écrit :
> > >>
> > >> > BCEL really needs the 6.0 release to be cut or it will no longer be
> > >> > compatible with any supported version of Java. Would anyone be able
> to
> > >> cut a
> > >> > new release?
> > >>
> > >> I will once the issues raised by Marks Roberts are addressed.
> > >>
> > >> Emmanuel Bourg
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > about.me/benmccann
> > >
> >
>
>
>
> --
> 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
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Feb 18, 2015 at 7:04 PM, Ben McCann <be...@benmccann.com> wrote:
> Would it be possible to release 6.0 now and release Mark's patches as 6.1
> or 7.0? I'm concerned it may be quite a long time before his patches are
> committed since they are not actively being reviewed and there is no
> activity on them for the past couple weeks.
>
> There is little downside to frequent releases in my experience. Infrequent
> releases on the other hand can be a source of frustration as it means it
> can be quite difficult to use the code that has been committed.
+1
Gary
> This is the
> exact reason the node.js community was splintered and the io.js fork was
> created. While end users can easily build from source it can become
> extremely difficult when there are multiple transitive dependencies relying
> on the library. Users end up having to maintain patched versions not only
> of BCEL but of the libraries that depend on BCEL which means there can be
> quite a bit of overhead. As the length of time between releases grows the
> number of custom patches each user has to separately maintain in each
> library depending on BCEL grows. Right now it has been nine years.
>
> Thanks,
> Ben
> On Feb 10, 2015 1:53 AM, "Ben McCann" <be...@benmccann.com> wrote:
>
> > Great, thanks for the update!
> >
> > Btw, for those not familiar with which issues those are, here's a list of
> > the ones Mark raised that are not yet resolved:
> > https://issues.apache.org/jira/browse/BCEL-79
> > https://issues.apache.org/jira/browse/BCEL-195
> > https://issues.apache.org/jira/browse/BCEL-196
> > https://issues.apache.org/jira/browse/BCEL-197
> > https://issues.apache.org/jira/browse/BCEL-198
> > https://issues.apache.org/jira/browse/BCEL-199
> > https://issues.apache.org/jira/browse/BCEL-200
> > https://issues.apache.org/jira/browse/BCEL-201
> > https://issues.apache.org/jira/browse/BCEL-202
> > https://issues.apache.org/jira/browse/BCEL-205
> > https://issues.apache.org/jira/browse/BCEL-206
> > https://issues.apache.org/jira/browse/BCEL-208
> > https://issues.apache.org/jira/browse/BCEL-209
> >
> > Thanks!
> > -Ben
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Feb 8, 2015 at 11:32 PM, Emmanuel Bourg <eb...@apache.org>
> wrote:
> >
> >> Le 09/02/2015 06:29, chengas123 a écrit :
> >>
> >> > BCEL really needs the 6.0 release to be cut or it will no longer be
> >> > compatible with any supported version of Java. Would anyone be able to
> >> cut a
> >> > new release?
> >>
> >> I will once the issues raised by Marks Roberts are addressed.
> >>
> >> Emmanuel Bourg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > about.me/benmccann
> >
>
--
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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 19/02/2015 04:04, Ben McCann a écrit :
> Would it be possible to release 6.0 now and release Mark's patches as 6.1
> or 7.0? I'm concerned it may be quite a long time before his patches are
> committed since they are not actively being reviewed and there is no
> activity on them for the past couple weeks.
Mark raised some important issues like BCEL-195, BCEL-200, BCEL-206,
BCEL-207, BCEL-208 and the reopening of BCEL-79. I think these issues
should be addressed for the next release and I invite anyone impatient
to see BCEL 6.0 released to review them, check the JVM spec and provide
test cases to ensure we fix them properly.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
Would it be possible to release 6.0 now and release Mark's patches as 6.1
or 7.0? I'm concerned it may be quite a long time before his patches are
committed since they are not actively being reviewed and there is no
activity on them for the past couple weeks.
There is little downside to frequent releases in my experience. Infrequent
releases on the other hand can be a source of frustration as it means it
can be quite difficult to use the code that has been committed. This is the
exact reason the node.js community was splintered and the io.js fork was
created. While end users can easily build from source it can become
extremely difficult when there are multiple transitive dependencies relying
on the library. Users end up having to maintain patched versions not only
of BCEL but of the libraries that depend on BCEL which means there can be
quite a bit of overhead. As the length of time between releases grows the
number of custom patches each user has to separately maintain in each
library depending on BCEL grows. Right now it has been nine years.
Thanks,
Ben
On Feb 10, 2015 1:53 AM, "Ben McCann" <be...@benmccann.com> wrote:
> Great, thanks for the update!
>
> Btw, for those not familiar with which issues those are, here's a list of
> the ones Mark raised that are not yet resolved:
> https://issues.apache.org/jira/browse/BCEL-79
> https://issues.apache.org/jira/browse/BCEL-195
> https://issues.apache.org/jira/browse/BCEL-196
> https://issues.apache.org/jira/browse/BCEL-197
> https://issues.apache.org/jira/browse/BCEL-198
> https://issues.apache.org/jira/browse/BCEL-199
> https://issues.apache.org/jira/browse/BCEL-200
> https://issues.apache.org/jira/browse/BCEL-201
> https://issues.apache.org/jira/browse/BCEL-202
> https://issues.apache.org/jira/browse/BCEL-205
> https://issues.apache.org/jira/browse/BCEL-206
> https://issues.apache.org/jira/browse/BCEL-208
> https://issues.apache.org/jira/browse/BCEL-209
>
> Thanks!
> -Ben
>
>
>
>
>
>
>
>
>
> On Sun, Feb 8, 2015 at 11:32 PM, Emmanuel Bourg <eb...@apache.org> wrote:
>
>> Le 09/02/2015 06:29, chengas123 a écrit :
>>
>> > BCEL really needs the 6.0 release to be cut or it will no longer be
>> > compatible with any supported version of Java. Would anyone be able to
>> cut a
>> > new release?
>>
>> I will once the issues raised by Marks Roberts are addressed.
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> about.me/benmccann
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
Great, thanks for the update!
Btw, for those not familiar with which issues those are, here's a list of
the ones Mark raised that are not yet resolved:
https://issues.apache.org/jira/browse/BCEL-79
https://issues.apache.org/jira/browse/BCEL-195
https://issues.apache.org/jira/browse/BCEL-196
https://issues.apache.org/jira/browse/BCEL-197
https://issues.apache.org/jira/browse/BCEL-198
https://issues.apache.org/jira/browse/BCEL-199
https://issues.apache.org/jira/browse/BCEL-200
https://issues.apache.org/jira/browse/BCEL-201
https://issues.apache.org/jira/browse/BCEL-202
https://issues.apache.org/jira/browse/BCEL-205
https://issues.apache.org/jira/browse/BCEL-206
https://issues.apache.org/jira/browse/BCEL-208
https://issues.apache.org/jira/browse/BCEL-209
Thanks!
-Ben
On Sun, Feb 8, 2015 at 11:32 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 09/02/2015 06:29, chengas123 a écrit :
>
> > BCEL really needs the 6.0 release to be cut or it will no longer be
> > compatible with any supported version of Java. Would anyone be able to
> cut a
> > new release?
>
> I will once the issues raised by Marks Roberts are addressed.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 09/02/2015 06:29, chengas123 a écrit :
> BCEL really needs the 6.0 release to be cut or it will no longer be
> compatible with any supported version of Java. Would anyone be able to cut a
> new release?
I will once the issues raised by Marks Roberts are addressed.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by chengas123 <be...@gmail.com>.
Hi,
The performance degradation issue with the UTF-8 cache has now been fixed:
https://issues.apache.org/jira/browse/BCEL-186
Java 7 is EOL (end-of-life) in April and will no longer receive updates at
that point in time.
http://www.oracle.com/technetwork/java/javase/downloads/eol-135779.html
BCEL really needs the 6.0 release to be cut or it will no longer be
compatible with any supported version of Java. Would anyone be able to cut a
new release?
Thanks,
Ben
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4672634.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Thank you for the reviews. I'll roll a new release candidate though to
address the cache issue reported by Konstantin.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Dave Brosius <db...@apache.org>.
+1
On 10/08/2014 01:54 PM, Jörg Schaible wrote:
> +1
>
> builds from source-tarball with my complete compiler zoo
>
> Emmanuel Bourg wrote:
>
>> Hi all,
>>
>> The third release candidate of BCEL is ready to pass under your scrutiny.
>>
>> Tag:
>> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC3/
>> (r1627908)
>>
>> Release notes:
>> http://people.apache.org/~ebourg/bcel/RELEASE-NOTES.txt
>>
>> Distribution files:
>> http://people.apache.org/~ebourg/bcel/
>>
>> Checksums (sha1):
>> 6f1d11224b7cea98ffbffa25d69d759fcd47421c bcel-6.0-bin.tar.gz
>> 425729b886f72481bdbfc7e8ca108f20c00e67ef bcel-6.0-bin.zip
>> 89e171be63df397d23ea746f9845cf3087e8467e bcel-6.0-src.tar.gz
>> a03c2e605b8eb997b5d023d6a7d6aa54fbf3600e bcel-6.0-src.zip
>>
>> Site:
>> http://people.apache.org/~ebourg/bcel/site/
>>
>> Javadoc:
>> http://people.apache.org/~ebourg/bcel/site/apidocs/
>>
>> Maven artifacts:
>>
> https://repository.apache.org/content/repositories/orgapachecommons-1047/org/apache/bcel/bcel/6.0/
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now.
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>> Thank you for your reviews,
>>
>> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release BCEL 6.0 based on RC3
Posted by Jörg Schaible <jo...@gmx.de>.
+1
builds from source-tarball with my complete compiler zoo
Emmanuel Bourg wrote:
> Hi all,
>
> The third release candidate of BCEL is ready to pass under your scrutiny.
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC3/
> (r1627908)
>
> Release notes:
> http://people.apache.org/~ebourg/bcel/RELEASE-NOTES.txt
>
> Distribution files:
> http://people.apache.org/~ebourg/bcel/
>
> Checksums (sha1):
> 6f1d11224b7cea98ffbffa25d69d759fcd47421c bcel-6.0-bin.tar.gz
> 425729b886f72481bdbfc7e8ca108f20c00e67ef bcel-6.0-bin.zip
> 89e171be63df397d23ea746f9845cf3087e8467e bcel-6.0-src.tar.gz
> a03c2e605b8eb997b5d023d6a7d6aa54fbf3600e bcel-6.0-src.zip
>
> Site:
> http://people.apache.org/~ebourg/bcel/site/
>
> Javadoc:
> http://people.apache.org/~ebourg/bcel/site/apidocs/
>
> Maven artifacts:
>
https://repository.apache.org/content/repositories/orgapachecommons-1047/org/apache/bcel/bcel/6.0/
>
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you for your reviews,
>
> Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org