groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Rocher <>
Subject Re: release process
Date Tue, 24 Jan 2017 14:45:04 GMT

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 <> 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

View raw message