Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
MIME-Version: 1.0
In-Reply-To: <CADQzvmk4Oo9rQA6E1TREekTPSzSOiAQeP=Urz4QG4ziGp5b4gw@mail.gmail.com>
References: <5880C018.3070204@gmx.org> <CAMbkE7TzfPPO8cRxzWvWcyv9SqVMumD_pG9OXqS+Z=LdysgD4w@mail.gmail.com>
 <f99ed6bd-ab85-333d-210c-4ce3c50e2abf@gmx.org> <CAMbkE7RQ-KR-1xdRTkTmcZ2pcvskLcnREENj-JQ1WFJXhz3pEQ@mail.gmail.com>
 <5882505D.1090304@gmx.org> <CAMbkE7R9kCc0dMSZXSxk3Pkzmc72d9ai1cNfSjur+yqLEXDESA@mail.gmail.com>
 <CADQzvmkrpOMDNrte4jfb8W-ajd6Fz=LiU5UBKVZeP167M9+EyQ@mail.gmail.com>
 <CAO_wNofgY4VNK3rdkH_GvTzV16BcVvy3oFy68qOGs-J+_N=98Q@mail.gmail.com>
 <cdf04552-c6f6-385e-d9ef-1d780279b16e@gmx.org> <CAO_wNodBKRtOqbzwYTTtGZLnbnH-p1x0d6UrYdrn_mHtc6LEdg@mail.gmail.com>
 <CADQzvmk4Oo9rQA6E1TREekTPSzSOiAQeP=Urz4QG4ziGp5b4gw@mail.gmail.com>
From: Graeme Rocher <graeme.rocher@gmail.com>
Date: Tue, 24 Jan 2017 16:02:31 +0100
Message-ID: <CAO_wNodHQmbGnCjA7c=riftUOXrrgOd1YELXKoPRWzr0CYYDZg@mail.gmail.com>
Subject: Re: release process
To: dev@groovy.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 24 Jan 2017 15:03:03 -0000

With Grails and GORM we plan to drop Java 7 support soon.

So a 2.9 (or whatever) would be nice to add to the release plan

Cheers

On Tue, Jan 24, 2017 at 3:51 PM, C=C3=A9dric Champeau
<cedric.champeau@gmail.com> 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, though.
>
> (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 <graeme.rocher@gmail.com>:
>>
>> 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 interfac=
e
>> > for
>> > example, then not really. groovy-compat would have to transform the co=
de
>> > using Groovy. Or we have a transform that will force the program to us=
e
>> > 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
>
>


--=20
Graeme Rocher