Re: release process

FYI, Jesper has ported Parrot to Java 7(https://github.com/apache/groovy/pull/485) 在 "Graeme Rocher-2 [via Groovy]" ，2017年1月31日 下午3:19写道： I am in agreement with doing a 3.0 compatible with Groovy 2.x and making 3.x into Groovy 4.x Groovy 2.x users who will be in the majority for a long time

Re: release process

And speaking of this pull request: the Antlr v4 JARs are built against Java 7 / JDK 7? On Tue, Jan 31, 2017 at 9:19 AM, Daniel Sun wrote: > FYI, Jesper has ported Parrot to Java 7(https://github.com/apache/ > groovy/pull/485) > > > > 在 "Graeme Rocher-2 [via Groovy]"

Re: release process

I have nothing against splitting the currently ear-marked 3.0 into 3 and 4 versions. We need to set expectations within the community when the time comes and at least for me there are a number of technical questions that spring to mind around parrot lambda syntax vs Java lambdas and JDK8 that I thi

[VOTE] Apache Groovy Roadmap

Hi guys, There are multiple conversations going on for weeks, and I think they are going nowhere. We could discuss for months what's the best plan for Groovy, without releasing anything. Here are the challenges that are waiting for us: 1. release a version of Groovy that integrates Groovy macros

Re: [VOTE] Apache Groovy Roadmap

YES from me. Would be great if we can deliver #1 as a macro method, not it form of "MacroGroovy" (and hopefully forget this awkward name collision :D ) Just want to remind that there is a PR waiting for a review where I rewrote it and implemented basic macro methods support: https://github.com/ap

Re: [VOTE] Apache Groovy Roadmap

YES for me too (forgot to answer :D). And yes, we should review (and merge) your PR before beta-1. 2017-01-31 9:44 GMT+01:00 Sergei Egorov : > YES from me. > > Would be great if we can deliver #1 as a macro method, not it form of > "MacroGroovy" (and hopefully forget this awkward name collision :

Re: [VOTE] Apache Groovy Roadmap

YES (not binding). This is a clear plan, and is easy to understand for the community. It makes way for a 2.5 soon, and it also puts Parrot in a release that is not too far into the future, which IMO is important. IMO a good plan. On Tue, 31 Jan 2017 at 09:45 Cédric Champeau wrote: > YES for me

Re: [VOTE] Apache Groovy Roadmap

In principle I'd say YES but I don't agree on Parrot being backported to 2.6 due to potential incompatibilities. I don't want users to have the same pain we had when switching between Groovy 1.7 and 1.8. IMHO Parrot should go on 3.x, thus the only parts of the roadmap I can safely vote YES are #1 a

Re: [VOTE] Apache Groovy Roadmap

Having Parrot available for immediate testing is the reason why I'd advocate for having 3.0-ea releases ;-) --- Java Champion; Groovy Enthusiast http://jroller.com/aalmiray http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system a

Re: [VOTE] Apache Groovy Roadmap

On 31.01.2017 09:37, Cédric Champeau wrote: Hi guys, There are multiple conversations going on for weeks, and I think they are going nowhere. We could discuss for months what's the best plan for Groovy, without releasing anything. Here are the challenges that are waiting for us: 1. release a

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 10:46 GMT+01:00 Jochen Theodorou : > > > On 31.01.2017 09:37, Cédric Champeau wrote: > >> Hi guys, >> >> There are multiple conversations going on for weeks, and I think they >> are going nowhere. We could discuss for months what's the best plan for >> Groovy, without releasing anything

Re: [VOTE] Apache Groovy Roadmap

Sorry if outsiders are not meant to chime in :) Why not - 2.5 as Cédric proposed (so Java 7 + macros) - 3.0 with Java 8 and Parrot - 4.0 with Java 9 and Jigsaw? This way Groovy versions and Java versions are nicely aligned. To let people try Parrot early, there could be a 3.0 early access rele

Re: [VOTE] Apache Groovy Roadmap

On 31 Jan 2017, at 10.46, Jochen Theodorou wrote: > > > On 31.01.2017 09:37, Cédric Champeau wrote: >> >> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7 >> - Groovy 3.0: integrate 3 and 5. The only version with necessary >> breaking changes (we have no choice here) > > If you

Re: [VOTE] Apache Groovy Roadmap

> De: "Alessio Stalla" > À: dev@groovy.apache.org > Envoyé: Mardi 31 Janvier 2017 11:04:00 > Objet: Re: [VOTE] Apache Groovy Roadmap > Sorry if outsiders are not meant to chime in :) > Why not > - 2.5 as Cédric proposed (so Java 7 + macros) > - 3.0 with Java 8 and Parrot > - 4.0 with Java 9 and

Re: release process

> On 31 Jan 2017, at 09.31, Guillaume Laforge wrote: > > And speaking of this pull request: the Antlr v4 JARs are built against Java 7 > / JDK 7? > Antlr4 runtime jars are Java6 (classfile version 50). I didn't try dropping down the parser down to 1.6, since I lack a 1.6 older JVMs on my curr

Re: [VOTE] Apache Groovy Roadmap

On 31.01.2017 11:11, Remi Forax wrote: [...] Jigsaw is more or less forward compatible, i.e. you can release jars that will use Java 8 to compile (or Java 9 in release mode 8) and also make them jigsaw compatible in term of dependencies. Obviously the module graph will be read only on Java 9 bu

Re: [VOTE] Apache Groovy Roadmap

[..] Were exactly was this leak? The antlr2 classes are jarjar'ed, right - they were hardly API. Or am I missing something? As for usage: A quick search on GitHub for the string 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and 'groovy-class-parser', in pretty old code. I a

Re: [VOTE] Apache Groovy Roadmap

I would be volunteering for checking if this is a problem in NetBeans Groovy Support. What are the patterns I should look for? Already any branch I could build and try as an experiment? Thanks Sven Am 31.01.2017 12:46 schrieb "Jochen Theodorou" : > [..] > >> Were exactly was this leak? The ant

Re: [VOTE] Apache Groovy Roadmap

YES from me. IMO we should not be waiting until 3.x for Parrot however, I am also ok with the proposal to change the roadmap so that Groovy 3.x is the Parrot release and Groovy 4.x the breaking Jigsaw/Java 8/9 release. The sooner we get folks testing Parrot in the real world the better and if we

Re: New Groovy parser now on JDK 1.7

Hi Jesper, Well done! Thanks a lot for your porting Parrot to Java 7 :) Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/New-Groovy-parser-now-on-JDK-1-7-tp5738237p5738270.html Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache Groovy Roadmap

Hi Cédric, > Because macro groovy doesn't have to be bound with breaking changes. If program has already used "macro" method name, what will happen? Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738271.html Sent fr

Re: [VOTE] Apache Groovy Roadmap

For the beta, it's not super important. For the release I mentioned I wanted an opt-in mechanism in the past, so it shouldn't be a breaking change. 2017-01-31 16:33 GMT+01:00 Daniel Sun : > Hi Cédric, > > > Because macro groovy doesn't have to be bound with breaking changes. > If program has alre

Re: release process

> On Jan 30, 2017, at 3:32 PM, Guillaume Laforge wrote: > > That's indeed another approach. > But that would mean two close major releases with breaking changes. Do you > think it'd be acceptable? Yes, particularly since the 3.0 release wouldn't (hopefully) really break anything, I just think

Re: [VOTE] Apache Groovy Roadmap

On Tue, 2017-01-31 at 09:37 +0100, Cédric Champeau wrote: > […] > > - [ ] YES, I approve the roadmap above > - [ ] NO, I do not approve the roadmap abobe beause... > - [ ] I don't mind, or this goes beyond what I can think of > > This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017. YE

Re: release process

On Mon, 2017-01-30 at 21:32 +0100, Guillaume Laforge wrote: > That's indeed another approach. > But that would mean two close major releases with breaking changes. > Do you > think it'd be acceptable? Major releases are what breaking changes are for. Or did I mean that the other way around. Havin

Re: [VOTE] Apache Groovy Roadmap

On 01/31/2017 09:37 AM, Cédric Champeau wrote: > Hi guys, > > There are multiple conversations going on for weeks, and I think they > are going nowhere. We could discuss for months what's the best plan for > Groovy, without releasing anything. Here are the challenges that are > waiting for us: >

Re: [VOTE] Apache Groovy Roadmap

YES (binding) On Tue, Jan 31, 2017 at 9:37 AM, Cédric Champeau wrote: > Hi guys, > > There are multiple conversations going on for weeks, and I think they are > going nowhere. We could discuss for months what's the best plan for Groovy, > without releasing anything. Here are the challenges that

Re: [VOTE] Apache Groovy Roadmap

No. I would like to vote YES as this is almost what I proposed in the "release process" thread, but I think I'm going to have to vote NO as there are potential breaking changes in 2.5 (requiring Java 1.7) and 2.6 (switching to Parrot). Hopefully Parrot doesn't break anything, but I don't know

Re: [VOTE] Apache Groovy Roadmap

Hi Suderman, > Hopefully Parrot doesn't break anything, but I don't know if that can be > asserted definitively at this point. Parrot passes all tests of Apache Groovy, so it conforms to GLS. In addition, Parrot can parse source code of Grails, Gradle, Spock, Geb. But I still hope your program co