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 work) 2) How to best design the semantics of lambda expressions in Groovy 3) How to deal with Groovy in JDK9 with or without breaking changes (i.e. still support Groovy 2.x in JDK9 WITHOUT Jigsaw, but only Groovy 3.x WITH Jigsaw, because of indy and new package names, which both break old classfiles and perhaps source). If we're very pedantic about semantic versions, we'll have to bump major numbers each time we raise the minimum runtime requirement. But - what if we're less pedantic? We could restate our semantic versioning interpretation to be that the 2.x line will be source code compatible with previous 2.x Groovy sources, but with higher JVM runtime environment requirements. I.e. you can still run your old Groovy-compiled classfiles with Groovy 2.x. So they're compatible, you just need a newer runtime... As for Parrot: It has been backported to 1.7, and while it would require testing, I can't see the reason for marking it a breaking change. I think we should raise these three discussion points as separate threads, and restart the vote, but with two flavours: YES-1: - Groovy 2.5: integrates macros and requires Java 7, to be released ASAP, we've been waiting for this for too long - Groovy 2.6: integrate Parrot, implying backporting Parrot to Java 7 - Groovy 3.0: integrate Jigsaw and drop old callsite caching + use indy. The only version with necessary breaking changes (we have no choice here) YES-2: - Groovy 3.0: integrates macros and requires Java 7, to be released ASAP, we've been waiting for this for too long - Groovy 3.1: integrate Parrot, implying backporting Parrot to Java 7 - Groovy 4.0: integrate Jigsaw and drop old callsite caching + use indy. The only version with necessary breaking changes (we have no choice here) So what will it be: - [ ] YES-1, I approve the roadmap with the pragmatic stance to compatibility - [ ] YES-2, I approve the roadmap above with the stricter stance towards compatibility - [ ] NO, I do not approve the roadmap abobe beause... - [ ] I don't mind, or this goes beyond what I can think of In the end, it's for the PMC to decide. -Jesper > On 7 Feb 2017, at 14.15, Cédric Champeau <cedric.champ...@gmail.com> wrote: > > The result is that the vote turned into a debate again. I give up :) > > 2017-02-07 4:18 GMT+01:00 Daniel Sun <realblue...@hotmail.com > <mailto:realblue...@hotmail.com>>: > 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 > > <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html> > Sent from the Groovy Dev mailing list archive at Nabble.com. >
