groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <>
Subject Re: Groovy 3.0
Date Mon, 01 Feb 2016 09:20:47 GMT
So one thing that could be useful already is to add stories either in
JIRA or github for each of these epic (in size) issues individually,
where all discussions can be followed. Then a Roadmap document could
list these "epics" as large things on the horizon, without any
specific order or deadline. Then a mapping to release dates could be
done once these epics are close to being done. Maybe such epics
already exist.

On Mon, Feb 1, 2016 at 10:05 AM, Jochen Theodorou <> wrote:
> On 31.01.2016 21:29, Thibault Kruse wrote:
>> Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
>> problem describing certain java8 features using whatever antlr version
>> is used right now?
> They are linked in that way, that it does not really make sense to do bigger
> syntax changes in antlr2, if we then want to go to antlr4 would be double
> work to do it for antlr2 and antlr4. But thats actually all that is to it.
>> I would assume that porting Groovy to Java9 takes precendence over
>> changing the syntax, so it would be nice to have a roadmap that decide
>> which version will contain which of those changes.
> We can make a "1 feature per version" style roadmap.. without target
> times... not sure if that really makes sense though. If someone wants to
> work on a new feature out of order (because for example that person has a
> fitting current skill set for that task, but not for the scheduled one),
> then I am not really against this person doing that. A roadmap might be
> problematic in that... so we imho need one for enduser information and one
> for developers
>> Given the scarce
>> resources it might be useful to separate these changes, but given that
>> the API will change in either case, it might be better to have one
>> avalanche of a change rather than annoying users multiple times.
> It is normally better to release more often. I would have released a beta on
> Groovy 2.5 for example a long time ago, even without the module part
> completed. And that is mainly because I have experienced dragged out
> releases in the past before Groovy 1.0, and what negative effects they have.
> But anyway... a change that breaks compatibility is different. So I agree...
> but given the sparse resources, I am afraid it would be too long too. Best
> would be to have a migration plan, do the breaking changes in one release,
> but back that with old logic... if that is possible.
> bye Jochen

View raw message