And speaking of this pull request: the Antlr v4 JARs are built against Java 7 / JDK 7?
On Tue, Jan 31, 2017 at 9:19 AM, 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] > <http:///user/SendEmail.jtp?type=node&node=5738247&i=0>>，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. > 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: Re: release process > <http://groovy.329449.n5.nabble.com/release-process-tp5737841p5738247.html> > > Sent from the Groovy Dev mailing list archive > <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at > Nabble.com. > -- 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>
