groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Laforge <glafo...@gmail.com>
Subject Re: release process
Date Tue, 31 Jan 2017 08:31:37 GMT
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 <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]
> <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>

Mime
View raw message