I will let the PMC decide on the exact numbering and what goes where. However;
+1 on getting Macros and Parrot out the door and available in a 2.x compatible
version as soon as possible.
> On Feb 7, 2017, at 9:59 AM, Jesper Steen Møller wrote:
>
> Well, I didn't see many actually object to t
Well, I didn't see many actually object to the contents or order that you
suggested, but primarily the numbering. I'll give it another go.
The vote thread seemed to raise three issues:
1) Whether or not to provide the parrot parser as a standalone option ASAP
(this is actually quite a bit of wor
On 07.02.2017 14:44, Daniel Sun wrote:
Hi Cédric,
It seems that too many choices are a annoying problem, but I
believe we can conquer it sooner or later ;)
BTW, is it possible to keep groovy' lambda expression as it
is(i.e. groovy closure with lambda syntax) but generate *real* lam
et.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_ins
Hi Cédric,
It seems that too many choices are a annoying problem, but I believe we
can conquer it sooner or later ;)
BTW, is it possible to keep groovy' lambda expression as it is(i.e.
groovy closure with lambda syntax) but generate *real* lambda bytecode for
it(https://github.com/a
The result is that the vote turned into a debate again. I give up :)
2017-02-07 4:18 GMT+01:00 Daniel Sun :
> Hi Cédric,
>
> 72h has gone. The result is ?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-Apache-Groovy-Roadmap-
I kind of got the impression that the thread seemed to turn into a
discussion thread - but happy to be corrected if others didn't get
that impression.
My impression was that there was a lot of consensus around what we
want in the next "non-bugfix" release (e.g. macros and jdk 7+) but
some fuzzines
Hi Cédric,
72h has gone. The result is ?
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
> On Feb 2, 2017, at 6:47 AM, Jesper Steen Møller wrote:
>
> 3. Major numbers should only be used if we mean to break stuff. Parrot
> shouldn't.
> On Feb 2, 2017, at 10:03 AM, Jochen Theodorou wrote:
>
> I would like to have a clarification on 2 things before we really make a new
> version
I would like to have a clarification on 2 things before we really make a
new version:
* is changing to java7 as default a breaking change and requires a new
major version? (that implies 3.0 soon and 4.0 for java8 not long after)
* is it acceptable to have optional java8 only components (for exa
As to the new features of Java 8, Parrot provides the same syntax but the
backend is based on the existing groovy runtime. The approach can make some
differences between Groovy and Java 8. Whether these differences are allowed or
not depends on GLS. Like the inner class behaves a bit differ
I'm in agreement that we should not commit to behaviour that we
believe to be wrong and later break it (i.e. lambda's)
So if we agree on a version that should be "the Parrot release"
whether that is 2.6 or 3.0 we have to scope into that work resolving
the semantics discussion.
Cheers
On Thu, Feb
Hi list
> On 2 Feb 2017, at 11.58, Paul King wrote:
>
> This thread has kind of gone into debate mode but I guess for the
> record I would be -1 on any releases having parrot that weren't marked
> as "experimental" or "incubating" until we thrash out future plans for
> dealing with Java 8 featur
This thread has kind of gone into debate mode but I guess for the
record I would be -1 on any releases having parrot that weren't marked
as "experimental" or "incubating" until we thrash out future plans for
dealing with Java 8 features (default methods on interfaces/"real"
lambda expressions). I d
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
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
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
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:
>
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
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
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
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
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
[..]
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
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
> 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
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
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
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
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
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
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
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
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 :
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
35 matches
Mail list logo
