groovy-dev mailing list archives

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

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.

Cheers

On Tue, Jan 24, 2017 at 3:03 PM, Jochen Theodorou <blackdrag@gmx.org> 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

Mime
View raw message