groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: release process
Date Tue, 31 Jan 2017 08:35:24 GMT
I have nothing against splitting the currently ear-marked 3.0 into 3
and 4 versions. We need to set expectations within the community when
the time comes and at least for me there are a number of technical
questions that spring to mind around parrot lambda syntax vs Java
lambdas and JDK8 that I think we need to work through in more detail.

On Tue, Jan 31, 2017 at 6:19 PM, Daniel Sun <realbluesun@hotmail.com> wrote:
> FYI, Jesper has ported Parrot to Java
> 7(https://github.com/apache/groovy/pull/485)
>
>
>
> 在 "Graeme Rocher-2 [via Groovy]" <ml-node+[hidden email]>,2017年1月31日
> 下午3:19写道:
>
> 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.
>>
>> -Jesper
>>
>>
>> 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, though.
>>>
>>>
>>> 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.
>>>
>>> Cheers,
>>> Keith
>>>
>>>
>>> (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]>:
>>>>
>>>> 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 <[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
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+
>
> --
> Graeme Rocher
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://groovy.329449.n5.nabble.com/release-process-tp5737841p5738246.html
> To unsubscribe from release process, click here.
> NAML
>
>
> ________________________________
> View this message in context: Re: release process
>
> Sent from the Groovy Dev mailing list archive at Nabble.com.

Mime
View raw message