groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suderman Keith <suder...@anc.org>
Subject Re: [VOTE] Apache Groovy Roadmap
Date Tue, 31 Jan 2017 20:57:58 GMT
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 if that can be asserted definitively at this point.

Keith

> On Jan 31, 2017, at 3: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