FYI, Jesper has ported Parrot to Java 7(https://github.com/apache/groovy/pull/485)
在 "Graeme Rocher-2 [via Groovy]" <ml-node+s329449n5738246...@n5.nabble.com>，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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts> -- 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<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737841&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzg0MXwxMTQ2MjE4MjI1>. NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> -- View this message in context: http://groovy.329449.n5.nabble.com/release-process-tp5737841p5738247.html Sent from the Groovy Dev mailing list archive at Nabble.com.
