Re: release process

2017-01-31 Thread Russel Winder
On Mon, 2017-01-30 at 21:32 +0100, Guillaume Laforge wrote: > That's indeed another approach. > But that would mean two close major releases with breaking changes. > Do you > think it'd be acceptable? Major releases are what breaking changes are for. Or did I mean that the other way around. Havin

Re: release process

2017-01-31 Thread Suderman Keith
> On Jan 30, 2017, at 3:32 PM, Guillaume Laforge wrote: > > That's indeed another approach. > But that would mean two close major releases with breaking changes. Do you > think it'd be acceptable? Yes, particularly since the 3.0 release wouldn't (hopefully) really break anything, I just think

Re: release process

2017-01-31 Thread Jesper Steen Møller
> On 31 Jan 2017, at 09.31, Guillaume Laforge wrote: > > And speaking of this pull request: the Antlr v4 JARs are built against Java 7 > / JDK 7? > Antlr4 runtime jars are Java6 (classfile version 50). I didn't try dropping down the parser down to 1.6, since I lack a 1.6 older JVMs on my curr

Re: release process

2017-01-31 Thread Paul King
>>> > >>>> > >>>> > 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.

Re: release process

2017-01-31 Thread Guillaume Laforge
things compatible again. >> > >> > bye Jochen >> >> >> >> -- >> Graeme Rocher >> >> >> >> >> >> >> -- >> Guillaume Laforge >> Apache Groovy committer & PMC Vice-President >> Developer Advocate @ Google Cloud Platform

Re: release process

2017-01-31 Thread Daniel Sun
FYI, Jesper has ported Parrot to Java 7(https://github.com/apache/groovy/pull/485) 在 "Graeme Rocher-2 [via Groovy]" ,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

Re: release process

2017-01-30 Thread Graeme Rocher
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 o

Re: release process

2017-01-30 Thread Jesper Steen Møller
> On 30 Jan 2017, at 21.32, Guillaume Laforge 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 breaki

Re: release process

2017-01-30 Thread Guillaume Laforge
That's indeed another approach. But that would mean two close major releases with breaking changes. Do you think it'd be acceptable? On Mon, Jan 30, 2017 at 7:37 PM, Suderman Keith wrote: > > On Jan 24, 2017, at 9:51 AM, Cédric Champeau > wrote: > > The main problem is parrot is that it requir

Re: release process

2017-01-30 Thread Suderman Keith
> On Jan 24, 2017, at 9:51 AM, Cédric Champeau > 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 > r

Re: release process

2017-01-25 Thread Daniel Sun
Hi Jesper, > I recognise that the Antlr4 parser AST building looks really neat in Java > 8, but easthetics aside That's why I choose Java 8 to rewrite the parser :) Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/release-process-tp5737841p5738020.html Se

Re: release process

2017-01-24 Thread Paul King
I plan to experiment with creating an "uber" jar (maybe using a different name) for 2.5 that would have the parrot parser. It would be like the indy jars for now, requiring a move into the correct directory to enable. But it isn't high up on my priority list just yet. Cheers, Paul. On Wed, Jan 2

Re: release process

2017-01-24 Thread Jesper Steen Møller
But - I recognise that the Antlr4 parser AST building looks really neat in Java 8, but easthetics aside, wouldn’t it we a relatively easy task to port back to Java 7? -Jesper > On 24 Jan 2017, at 16.59, Jochen Theodorou wrote: > > > > On 24.01.2017 15:51, Cédric Champeau wrote: >> The main

Re: release process

2017-01-24 Thread Jochen Theodorou
On 24.01.2017 18:08, Cédric Champeau wrote: [...] you misunderstand one essential part here. The parrot module would require java8, building Groovy would require Java8, executing Groovy would not require Java8 as long as parrot is not used. I do understand this. But we're talking abo

Re: release process

2017-01-24 Thread Cédric Champeau
2017-01-24 16:59 GMT+01:00 Jochen Theodorou : > > > On 24.01.2017 15:51, Cédric Champeau 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

Re: release process

2017-01-24 Thread Jochen Theodorou
On 24.01.2017 15:51, Cédric Champeau 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 simi

Re: release process

2017-01-24 Thread Jochen Theodorou
On 24.01.2017 15:45, Graeme Rocher wrote: 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. nope, we are on the

Re: release process

2017-01-24 Thread Graeme Rocher
With Grails and GORM we plan to drop Java 7 support soon. So a 2.9 (or whatever) would be nice to add to the release plan Cheers On Tue, Jan 24, 2017 at 3:51 PM, Cédric Champeau wrote: > The main problem is parrot is that it requires Java 8, and 2.5 is planned to > support 1.7. And bundling suc

Re: release process

2017-01-24 Thread Cédric Champeau
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. (as a side not

Re: release process

2017-01-24 Thread Graeme Rocher
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 wrote:

Re: release process

2017-01-24 Thread Jochen Theodorou
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

Re: release process

2017-01-24 Thread Graeme Rocher
So if the changes are required for Java 9 then I guess breaking binary compatibility is justifiable. What I would like us to consider then is a Java 8 + Parrot release that is binary compatible. I think it would be a real shame that using Parrot required updating to a version that is not compatib

Re: release process

2017-01-24 Thread Cédric Champeau
2017-01-24 14:50 GMT+01:00 Graeme Rocher : > 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 JD

Re: release process

2017-01-24 Thread Graeme Rocher
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. Is there a way to re

Re: release process

2017-01-22 Thread Cédric Champeau
We can release 2.5.0-beta-1 and 3.0.0-alpha-1 concurrently. I see no problem with that. And it would be cleaner. If we release, say, 2.5 final with parrot as an optional module, nothing prevents people from using it real projects. I don't think we want to pay the price of maintaining parrot for 2.5

Re: release process

2017-01-20 Thread Jochen Theodorou
On 20.01.2017 22:04, Cédric Champeau wrote: Let me rephrase what I said. My concern is not about complexity. My concern is that parrot is an experimental parser, that requires Java 8, and an additional dependency, antlr4, which conflicts with an existing dependency, antlr2. antlr2 and antrl4 ar

Re: release process

2017-01-20 Thread Cédric Champeau
Let me rephrase what I said. My concern is not about complexity. My concern is that parrot is an experimental parser, that requires Java 8, and an additional dependency, antlr4, which conflicts with an existing dependency, antlr2. I don't want to mix things like that. The new parser should be, as a

Re: release process

2017-01-20 Thread Paul King
The concern was added complexity but maybe it isn't much different to normal. From my side, I need to play around some more to confirm either way. At a minimum, we'd need to use java 8 to do the 2.5.x releases, and have something sensible built, i.e. without the parrot option, for those compiling

Re: release process

2017-01-20 Thread Jochen Theodorou
On 20.01.2017 13:14, Paul King wrote: Wasn't the consensus to have parrot just in 3.0? So we could make the 2_5_X branch now? may have missed something like a consensus I guess. But frankly I don´t get why parrot should not even be optional in 2.5.x. bye Jochen

Re: release process

2017-01-20 Thread Paul King
Wasn't the consensus to have parrot just in 3.0? So we could make the 2_5_X branch now? On 20 Jan 2017 8:08 PM, "Jochen Theodorou" wrote: > > > On 19.01.2017 20:07, Paul King wrote: > >> +1 with a few comments below. >> >> There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and >> 3

Re: release process

2017-01-20 Thread Jochen Theodorou
On 19.01.2017 20:07, Paul King wrote: +1 with a few comments below. There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and 3.0.0-ea-1. Perhaps we should split between us? I'd suggest I do the first two with you as "co-pilot" and swap roles for the third? the first two time-wise

Re: release process

2017-01-19 Thread Paul King
+1 with a few comments below. There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and 3.0.0-ea-1. Perhaps we should split between us? I'd suggest I do the first two with you as "co-pilot" and swap roles for the third? Wrt promoting our release process/scripts, I'd probably hold off a