groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergei Egorov <bsid...@gmail.com>
Subject Re: [VOTE] Apache Groovy Roadmap
Date Tue, 31 Jan 2017 08:44:05 GMT
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/apache/groovy/pull/472/files


BR,
Sergei

On Tue, Jan 31, 2017 at 10:37 AM C├ędric Champeau <cchampeau@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.
>
>

Mime
View raw message