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 <realblue...@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.
