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 and #3. Given the set of voting options we've got my vote is NO.
My proposed roadmap would be then - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting for this for too long - Groovy 3.0: integrate 3, 4 and 5. The only version with necessary breaking changes (we have no choice here) Cheers, Andres ------------------------------------------- Java Champion; Groovy Enthusiast http://jroller.com/aalmiray http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Tue, Jan 31, 2017 at 9:37 AM, Cédric Champeau <cchamp...@apache.org> 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 version of Groovy that integrates Groovy macros > 2. upgrade the minimal runtime required for Groovy to 1.7, which is > required to smoothly transition to higher requirements (and also, make our > devs lives easier) > 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to > drop the old call site caching and use indy Groovy everywhere > 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4 > 5. compatibility with Jigsaw, aka "Groovy as a module" > > I would like to propose the following plan: > > - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting > for this for too long > - 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) > > This plan is, I think, a good compromise for all the requirements we have: > backwards compatibility, and making progress and not having too many > branches. An alternative would be to keep Parrot on Java 8, but as some of > us have said, this is incompatible with a soonish release. The drawback is > that Parrot has the risk of being a breaking change (it is, typically if > people implicitly depend on the old parser, which would be bad), so there's > a risk of not following semantic versioning. > > - [ ] 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. > >
