groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Sun <>
Subject Re: release process
Date Tue, 31 Jan 2017 08:19:34 GMT
FYI, Jesper has ported Parrot to Java 7(

在 "Graeme Rocher-2 [via Groovy]" <>,2017年1月31日

I am in agreement with doing a 3.0 compatible with Groovy 2.x and making 3.x into Groovy 4.x

Groovy 2.x users who will be in the majority for a long time shouldn't have to wait for breaking
changed to get Parrot

Also as stupid as it is having higher version numbers will also increase perception of maturity.

On Mon, 30 Jan 2017 at 23:10, Jesper Steen Møller <[hidden email]> wrote:
On 30 Jan 2017, at 21.32, Guillaume Laforge <[hidden email]> wrote:

That's indeed another approach.
But that would mean two close major releases with breaking changes. Do you think it'd be acceptable?

If the testing is suffciently solid, how would shipping Groovy with Parrot (for Java 7) a
breaking change (using jarjar'ed Antlr4)?

Upping the JVM requirement will break things. Supporting Jigsaw will, too. So will a new MOP.
Parrot does none of those things.


On Mon, Jan 30, 2017 at 7:37 PM, Suderman Keith <[hidden email]> wrote:

On Jan 24, 2017, at 9:51 AM, Cédric Champeau <[hidden email]> wrote:

The main problem is parrot is that it requires Java 8, and 2.5 is planned to support 1.7.
And bundling such a core thing as an experimental, optional module is a no-go for me (imagine
the bug reports...). We could have a 2.9 release (or something similar) with Parrot sooner,

Maybe it is time to rethink the Groovy roadmap with respect to version numbers?  For example,
something like

2.x Continue as is
3.x Java 1.7 + Parrot.  Maintain binary compatibility as much as possible. (was 2.9)
4.x Java 1.8 + Parrot + Jigsaw (was 3.0)

This would make 4.x the new "blow up everything" release.  Personally I consider a move from
Java 1.7 -> Java 1.8 a breaking change and should not be done in a 2.x release.  This roadmap
would clearly separate upgrades and breaking changes while still allowing people to start
using Parrot in what is essentially 2.x as soon as possible.


(as a side note, any release of Groovy that would require Java 8 would be a no-go for Gradle
in short term, be it 2.x or 3.x)

2017-01-24 15:45 GMT+01:00 Graeme Rocher <[hidden email]>:

I still think it would be valuable to have a Parrot + Java 8 + Groovy
2.x release before Groovy 3.x

Maybe I am alone here, but it seems a shame that actual users won't
get to benefit from Parrot for quite a few years.


On Tue, Jan 24, 2017 at 3:03 PM, Jochen Theodorou <[hidden email]> wrote:
> On 24.01.2017 14:50, Graeme Rocher wrote:
>> Is the plan for 3.0 to break binary compatibility for existing libraries?
>> Personally I don't think we should ever have a version that we call
>> "blow everything up version" that would be a big red flag for me.
>> Imagine Oracle announcing the Java JDK "blow everything up" edition.
> you mean like Java9 with jigsaw?
>> Is there a way to retain some form of binary compatibility maybe
>> through `groovy-compat` that contains the old call site caching?
> That depends. If we want to change Closure to be a functional interface for
> example, then not really. groovy-compat would have to transform the code
> using Groovy. Or we have a transform that will force the program to use the
> old closures, then we can still solve the issue.
> In other words, I think we should develop freely till we have what we want
> and then think about how to make things compatible again.
> bye Jochen

Graeme Rocher

Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Social: @glaforge<> / Google+<>
Graeme Rocher

If you reply to this email, your message will be added to the discussion below:
To unsubscribe from release process, click here<>.

View this message in context:
Sent from the Groovy Dev mailing list archive at
View raw message