> De: "Alessio Stalla" <alessiosta...@gmail.com> > À: 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 Jigsaw? 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 but the classpath will work on Java 8 (and on Java 9). > This way Groovy versions and Java versions are nicely aligned. To let people > try > Parrot early, there could be a 3.0 early access release that only replaces the > antlr2-based parser with Parrot and bumps the required Java version to 8. Rémi > On 31 January 2017 at 10:55, Cédric Champeau < cedric.champ...@gmail.com > > wrote: >> 2017-01-31 10:46 GMT+01:00 Jochen Theodorou < blackd...@gmx.org > : >>> 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 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) >>> If you insist on a removal of antlr2, then this will be a breaking change, >>> since >>> we leak antlr2 classes in several places. 2.6 is then only an option if >>> antlr2 >>> stays. And considering your earlier statements that there should be only one >>> parser, that means 2.6 has to be 3.0. >>> And considering that there is now a Java7 version of Parrot and that there >>> will >>> be at least two major versions before we are on JDK8... why not just go with >>> 3.0 right away? >> Because macro groovy doesn't have to be bound with breaking changes. >>> So my -1 based on your argumentation from my side. An alternative plan: >>> no 2.5 >>> - 3.0 with macro methods and Java7 and parrot >>> - 4.0 java8 and jigsaw >>> bye Jochen
