You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2018/05/18 11:20:46 UTC
2.5.0-rc-3
Last call for changes in rc-3. I hope to prepare the candidate for voting
tomorrow.
If all goes well, please then consider the 2_5_X branch semi-frozen. We
still want to make changes to fix any bugs etc. but will want extra
scrutiny to make sure nothing breaks. There is probably doco changes and
such that needs updating too if anyone has some spare cycles, e.g. the 2.5
release notes on the groovy website or any TBDs in the adoc files.
Pending successful voting for rc-3 and then any feedback on the release,
the plan will be to release the final version about a week later.
Cheers, Paul.
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by Jesper Steen Møller <je...@selskabet.org>.
On 23 May 2018, at 13.24, Cédric Champeau <ce...@gmail.com> wrote:
>
> +1, regarding indy by default, I wonder if we could provide the "old" MOP as a backward compatibility runtime jar...
>
Yes, but that would be pretty tricky if we want to target JPMS too, due to split packages.
I wonder if it'd be possible to split it all up into (JPMS) modules like this:
groovy-core
groovy-compiler
groovy-xml
groovy-cli
...
And then provide a "Groovy 2.x" compatibility JARs for stuff like MOP1 compatibility, modules that have moved, etc. and provide that in the groovy-all jar?
-Jesper
> Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller <jesper@selskabet.org <ma...@selskabet.org>> a écrit :
>
> > On 23 May 2018, at 12.23, Russel Winder <russel@winder.org.uk <ma...@winder.org.uk>> wrote:
> >
> > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
> >> No plans to go to 18/19 model at this stage.
> >>
> >> If we push for an early 3.0, some of the breaking changes will have to be
> >> deferred.
> >> A very quick release after 3.0 could easily be a 3.1 if it was needed.
> >>
> >> The next major release (4.0) would be when we had tackled (a significant
> >> chunk of) the remaining breaking changes.
> >>
> >
> > I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per se.
> >
> > In the current climate is a 3.0 now, 4.0 in the next year actually a problem?
> >
> > Given the very volunteer nature of the Groovy project, pragmatism more than
> > anything has to be the order of the day. However I think there is a marketing
> > element here. Having new 2.4.X releases doesn't really achieve anything
> > marketing-wise. Releasing 2.5.0 actually doesn't much either really, though
> > clearly we do it as we are already at RC-3, and it can be "milked". But 2.5 is
> > just backward compatible extensions to 2.4, is this Groovy actually
> > progressing?
> >
> > I suggest we want to get a 3.0 out to show Groovy is progressing and with some
> > breaking changes, in particular JDK8+ only, not to mention a parser based on
> > somewhat newer technology! "Groovy drops support for JDK7" is probably a good
> > thing marketing wise.
> >
> > My feeling is that Groovy does not have enough resource to go for big major
> > version number releases, but that it needs something to combat the "it's old
> > technology" feel given the rise of Kotlin. I'd push for a 3.0 release soon and
> > worry about the metamodel changes later – unless they are already in place?
> >
>
> I agree with the soft factors around numbering.
>
>
> As I understand, the metamodel changes are not in place yet, and not on anybody's immediate schedule.
>
> A) However, as I understand it, MOP2 could be made backwards compatible, so that a new MOP2 runtime could still honor the MOP1 protocol, from some version 3.x onwards. We could then deprecate the MOP1 way of doing things.
>
> B) As for the indy stuff, we should choose to produce indy-only bytecodes now that we require Java 8 for Groovy 3.0. Again, we still need runtime support for the existing CallSite caching, or we'd have to force everybody to recompile every Groovy library they use. That's hardly a good idea!
>
> C) Finally, for 3.0 we could switch generation of closures to be bootstrap-driven, i.e. by keeping the closure body as a method of the enclosing class, but by generating the closure in the fashion of LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce the cost of using closures (all those extra classfiles). We could possibly introduce a ClosureInterface for forwards compatibility, and deprecate the use of the Closure class directly.
>
> Then, in some future majorversion 4.0, we could stop supporting MOP1, we could drop support for the old callsite caching, and we could make
>
> Was that about right?
>
> -Jesper
>
>
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by Paul King <pa...@asert.com.au>.
yes, performance is one of the things we need to look at
On Thu, May 24, 2018 at 12:24 AM, Daniel.Sun <su...@apache.org> wrote:
> > I wonder if we could provide the "old" MOP as a backward compatibility
> runtime jar...
>
> +1
>
> P.S. when indy is enabled by default, Groovy's performance goes worse...
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by "Daniel.Sun" <su...@apache.org>.
> I wonder if we could provide the "old" MOP as a backward compatibility
runtime jar...
+1
P.S. when indy is enabled by default, Groovy's performance goes worse...
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by Cédric Champeau <ce...@gmail.com>.
+1, regarding indy by default, I wonder if we could provide the "old" MOP
as a backward compatibility runtime jar...
Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller <je...@selskabet.org> a
écrit :
>
> > On 23 May 2018, at 12.23, Russel Winder <ru...@winder.org.uk> wrote:
> >
> > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
> >> No plans to go to 18/19 model at this stage.
> >>
> >> If we push for an early 3.0, some of the breaking changes will have to
> be
> >> deferred.
> >> A very quick release after 3.0 could easily be a 3.1 if it was needed.
> >>
> >> The next major release (4.0) would be when we had tackled (a significant
> >> chunk of) the remaining breaking changes.
> >>
> >
> > I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per
> se.
> >
> > In the current climate is a 3.0 now, 4.0 in the next year actually a
> problem?
> >
> > Given the very volunteer nature of the Groovy project, pragmatism more
> than
> > anything has to be the order of the day. However I think there is a
> marketing
> > element here. Having new 2.4.X releases doesn't really achieve anything
> > marketing-wise. Releasing 2.5.0 actually doesn't much either really,
> though
> > clearly we do it as we are already at RC-3, and it can be "milked". But
> 2.5 is
> > just backward compatible extensions to 2.4, is this Groovy actually
> > progressing?
> >
> > I suggest we want to get a 3.0 out to show Groovy is progressing and
> with some
> > breaking changes, in particular JDK8+ only, not to mention a parser
> based on
> > somewhat newer technology! "Groovy drops support for JDK7" is probably
> a good
> > thing marketing wise.
> >
> > My feeling is that Groovy does not have enough resource to go for big
> major
> > version number releases, but that it needs something to combat the "it's
> old
> > technology" feel given the rise of Kotlin. I'd push for a 3.0 release
> soon and
> > worry about the metamodel changes later – unless they are already in
> place?
> >
>
> I agree with the soft factors around numbering.
>
>
> As I understand, the metamodel changes are not in place yet, and not on
> anybody's immediate schedule.
>
> A) However, as I understand it, MOP2 could be made backwards compatible,
> so that a new MOP2 runtime could still honor the MOP1 protocol, from some
> version 3.x onwards. We could then deprecate the MOP1 way of doing things.
>
> B) As for the indy stuff, we should choose to produce indy-only bytecodes
> now that we require Java 8 for Groovy 3.0. Again, we still need runtime
> support for the existing CallSite caching, or we'd have to force everybody
> to recompile every Groovy library they use. That's hardly a good idea!
>
> C) Finally, for 3.0 we could switch generation of closures to be
> bootstrap-driven, i.e. by keeping the closure body as a method of the
> enclosing class, but by generating the closure in the fashion of
> LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce
> the cost of using closures (all those extra classfiles). We could possibly
> introduce a ClosureInterface for forwards compatibility, and deprecate the
> use of the Closure class directly.
>
> Then, in some future majorversion 4.0, we could stop supporting MOP1, we
> could drop support for the old callsite caching, and we could make
>
> Was that about right?
>
> -Jesper
>
>
>
Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by Jesper Steen Møller <je...@selskabet.org>.
> On 23 May 2018, at 12.23, Russel Winder <ru...@winder.org.uk> wrote:
>
> On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
>> No plans to go to 18/19 model at this stage.
>>
>> If we push for an early 3.0, some of the breaking changes will have to be
>> deferred.
>> A very quick release after 3.0 could easily be a 3.1 if it was needed.
>>
>> The next major release (4.0) would be when we had tackled (a significant
>> chunk of) the remaining breaking changes.
>>
>
> I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per se.
>
> In the current climate is a 3.0 now, 4.0 in the next year actually a problem?
>
> Given the very volunteer nature of the Groovy project, pragmatism more than
> anything has to be the order of the day. However I think there is a marketing
> element here. Having new 2.4.X releases doesn't really achieve anything
> marketing-wise. Releasing 2.5.0 actually doesn't much either really, though
> clearly we do it as we are already at RC-3, and it can be "milked". But 2.5 is
> just backward compatible extensions to 2.4, is this Groovy actually
> progressing?
>
> I suggest we want to get a 3.0 out to show Groovy is progressing and with some
> breaking changes, in particular JDK8+ only, not to mention a parser based on
> somewhat newer technology! "Groovy drops support for JDK7" is probably a good
> thing marketing wise.
>
> My feeling is that Groovy does not have enough resource to go for big major
> version number releases, but that it needs something to combat the "it's old
> technology" feel given the rise of Kotlin. I'd push for a 3.0 release soon and
> worry about the metamodel changes later – unless they are already in place?
>
I agree with the soft factors around numbering.
As I understand, the metamodel changes are not in place yet, and not on anybody's immediate schedule.
A) However, as I understand it, MOP2 could be made backwards compatible, so that a new MOP2 runtime could still honor the MOP1 protocol, from some version 3.x onwards. We could then deprecate the MOP1 way of doing things.
B) As for the indy stuff, we should choose to produce indy-only bytecodes now that we require Java 8 for Groovy 3.0. Again, we still need runtime support for the existing CallSite caching, or we'd have to force everybody to recompile every Groovy library they use. That's hardly a good idea!
C) Finally, for 3.0 we could switch generation of closures to be bootstrap-driven, i.e. by keeping the closure body as a method of the enclosing class, but by generating the closure in the fashion of LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce the cost of using closures (all those extra classfiles). We could possibly introduce a ClosureInterface for forwards compatibility, and deprecate the use of the Closure class directly.
Then, in some future majorversion 4.0, we could stop supporting MOP1, we could drop support for the old callsite caching, and we could make
Was that about right?
-Jesper
Re: 2.5.0-rc-3
Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
> No plans to go to 18/19 model at this stage.
>
> If we push for an early 3.0, some of the breaking changes will have to be
> deferred.
> A very quick release after 3.0 could easily be a 3.1 if it was needed.
>
> The next major release (4.0) would be when we had tackled (a significant
> chunk of) the remaining breaking changes.
>
I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per se.
In the current climate is a 3.0 now, 4.0 in the next year actually a problem?
Given the very volunteer nature of the Groovy project, pragmatism more than
anything has to be the order of the day. However I think there is a marketing
element here. Having new 2.4.X releases doesn't really achieve anything
marketing-wise. Releasing 2.5.0 actually doesn't much either really, though
clearly we do it as we are already at RC-3, and it can be "milked". But 2.5 is
just backward compatible extensions to 2.4, is this Groovy actually
progressing?
I suggest we want to get a 3.0 out to show Groovy is progressing and with some
breaking changes, in particular JDK8+ only, not to mention a parser based on
somewhat newer technology! "Groovy drops support for JDK7" is probably a good
thing marketing wise.
My feeling is that Groovy does not have enough resource to go for big major
version number releases, but that it needs something to combat the "it's old
technology" feel given the rise of Kotlin. I'd push for a 3.0 release soon and
worry about the metamodel changes later – unless they are already in place?
--
Russel.
==========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: 2.5.0-rc-3
Posted by mg <mg...@arscreat.com>.
Hi Paul & Russel,
thank you for claryfying that. Do you have a rough idea what an early 3.0 release would mean time-and feature wise ?
Cheers,mg
-------- Ursprüngliche Nachricht --------Von: Paul King <pa...@asert.com.au> Datum: 22.05.18 16:28 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: 2.5.0-rc-3
No plans to go to 18/19 model at this stage.
If we push for an early 3.0, some of the breaking changes will have to be deferred.A very quick release after 3.0 could easily be a 3.1 if it was needed.
The next major release (4.0) would be when we had tackled (a significant chunk of) the remaining breaking changes.
Cheers, Paul.
On Tue, May 22, 2018 at 11:06 PM, mg <mg...@arscreat.com> wrote:
Is the intention to switch to a rapid major release cycle like Windows, Java, etc ? If yes: Shouldn't we then call the next major release Groovy 18 (or 19, depending on year of release) ?
Could also be: groovy 2.6 -> groovy 18.0groovy 3.0 -> groovy 19.0
What exactly would be in 4.0 ? Going to 4.0 quickly after 3.0 seems to devalue to me what an old school major release encompasses/means (with regards to expectations/press coverage/etc)... (?)
-------- Ursprüngliche Nachricht --------Von: Cédric Champeau <ce...@gmail.com> Datum: 22.05.18 13:31 (GMT+01:00) An: dev@groovy.apache.org Cc: Paul King <pa...@asert.com.au> Betreff: Re: 2.5.0-rc-3
Yeah. Doesn't prevent us from having a quick 4.0 with module revamp if we're extremely good :)
Le mar. 22 mai 2018 à 13:29, Jesper Steen Møller <je...@selskabet.org> a écrit :
And postpone module revamp?
-Jesper
On 22 May 2018, at 13.27, Cédric Champeau <ce...@gmail.com> wrote:
I think we should slim down what Groovy 3 is, make it Parrot + JDK 8 basically.
Le mar. 22 mai 2018 à 13:22, Paul King <pa...@asert.com.au> a écrit :
The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+ sooner.
On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <su...@apache.org> wrote:
As a user, if you ask me whether I need the Parrot or not, my answer will
always be yes even if I seldom use it ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
No plans to go to 18/19 model at this stage.
If we push for an early 3.0, some of the breaking changes will have to be
deferred.
A very quick release after 3.0 could easily be a 3.1 if it was needed.
The next major release (4.0) would be when we had tackled (a significant
chunk of) the remaining breaking changes.
Cheers, Paul.
On Tue, May 22, 2018 at 11:06 PM, mg <mg...@arscreat.com> wrote:
> Is the intention to switch to a rapid major release cycle like Windows,
> Java, etc ? If yes: Shouldn't we then call the next major release Groovy 18
> (or 19, depending on year of release) ?
>
> Could also be:
> groovy 2.6 -> groovy 18.0
> groovy 3.0 -> groovy 19.0
>
> What exactly would be in 4.0 ? Going to 4.0 quickly after 3.0 seems to
> devalue to me what an old school major release encompasses/means (with
> regards to expectations/press coverage/etc)... (?)
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Cédric Champeau <ce...@gmail.com>
> Datum: 22.05.18 13:31 (GMT+01:00)
> An: dev@groovy.apache.org
> Cc: Paul King <pa...@asert.com.au>
> Betreff: Re: 2.5.0-rc-3
>
> Yeah. Doesn't prevent us from having a quick 4.0 with module revamp if
> we're extremely good :)
>
> Le mar. 22 mai 2018 à 13:29, Jesper Steen Møller <je...@selskabet.org> a
> écrit :
>
>> And postpone module revamp?
>>
>> -Jesper
>>
>> On 22 May 2018, at 13.27, Cédric Champeau <ce...@gmail.com>
>> wrote:
>>
>> I think we should slim down what Groovy 3 is, make it Parrot + JDK 8
>> basically.
>>
>> Le mar. 22 mai 2018 à 13:22, Paul King <pa...@asert.com.au> a écrit :
>>
>>> The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+
>>> sooner.
>>>
>>>
>>> On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <su...@apache.org> wrote:
>>>
>>>> As a user, if you ask me whether I need the Parrot or not, my answer
>>>> will
>>>> always be yes even if I seldom use it ;-)
>>>>
>>>> Cheers,
>>>> Daniel.Sun
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>>
>>>
>>>
>>
Re: 2.5.0-rc-3
Posted by mg <mg...@arscreat.com>.
Is the intention to switch to a rapid major release cycle like Windows, Java, etc ? If yes: Shouldn't we then call the next major release Groovy 18 (or 19, depending on year of release) ?
Could also be: groovy 2.6 -> groovy 18.0groovy 3.0 -> groovy 19.0
What exactly would be in 4.0 ? Going to 4.0 quickly after 3.0 seems to devalue to me what an old school major release encompasses/means (with regards to expectations/press coverage/etc)... (?)
-------- Ursprüngliche Nachricht --------Von: Cédric Champeau <ce...@gmail.com> Datum: 22.05.18 13:31 (GMT+01:00) An: dev@groovy.apache.org Cc: Paul King <pa...@asert.com.au> Betreff: Re: 2.5.0-rc-3
Yeah. Doesn't prevent us from having a quick 4.0 with module revamp if we're extremely good :)
Le mar. 22 mai 2018 à 13:29, Jesper Steen Møller <je...@selskabet.org> a écrit :
And postpone module revamp?
-Jesper
On 22 May 2018, at 13.27, Cédric Champeau <ce...@gmail.com> wrote:
I think we should slim down what Groovy 3 is, make it Parrot + JDK 8 basically.
Le mar. 22 mai 2018 à 13:22, Paul King <pa...@asert.com.au> a écrit :
The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+ sooner.
On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <su...@apache.org> wrote:
As a user, if you ask me whether I need the Parrot or not, my answer will
always be yes even if I seldom use it ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: 2.5.0-rc-3
Posted by Cédric Champeau <ce...@gmail.com>.
Yeah. Doesn't prevent us from having a quick 4.0 with module revamp if
we're extremely good :)
Le mar. 22 mai 2018 à 13:29, Jesper Steen Møller <je...@selskabet.org> a
écrit :
> And postpone module revamp?
>
> -Jesper
>
> On 22 May 2018, at 13.27, Cédric Champeau <ce...@gmail.com>
> wrote:
>
> I think we should slim down what Groovy 3 is, make it Parrot + JDK 8
> basically.
>
> Le mar. 22 mai 2018 à 13:22, Paul King <pa...@asert.com.au> a écrit :
>
>> The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+
>> sooner.
>>
>>
>> On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <su...@apache.org> wrote:
>>
>>> As a user, if you ask me whether I need the Parrot or not, my answer will
>>> always be yes even if I seldom use it ;-)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
>
Re: 2.5.0-rc-3
Posted by Jesper Steen Møller <je...@selskabet.org>.
And postpone module revamp?
-Jesper
> On 22 May 2018, at 13.27, Cédric Champeau <ce...@gmail.com> wrote:
>
> I think we should slim down what Groovy 3 is, make it Parrot + JDK 8 basically.
>
> Le mar. 22 mai 2018 à 13:22, Paul King <paulk@asert.com.au <ma...@asert.com.au>> a écrit :
> The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+ sooner.
>
>
> On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <sunlan@apache.org <ma...@apache.org>> wrote:
> As a user, if you ask me whether I need the Parrot or not, my answer will
> always be yes even if I seldom use it ;-)
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html>
>
Re: 2.5.0-rc-3
Posted by Cédric Champeau <ce...@gmail.com>.
I think we should slim down what Groovy 3 is, make it Parrot + JDK 8
basically.
Le mar. 22 mai 2018 à 13:22, Paul King <pa...@asert.com.au> a écrit :
> The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+ sooner.
>
>
> On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <su...@apache.org> wrote:
>
>> As a user, if you ask me whether I need the Parrot or not, my answer will
>> always be yes even if I seldom use it ;-)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>
Re: 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+ sooner.
On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <su...@apache.org> wrote:
> As a user, if you ask me whether I need the Parrot or not, my answer will
> always be yes even if I seldom use it ;-)
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: 2.5.0-rc-3
Posted by "Daniel.Sun" <su...@apache.org>.
As a user, if you ask me whether I need the Parrot or not, my answer will
always be yes even if I seldom use it ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
On Mon, May 21, 2018 at 2:49 AM, Daniel.Sun <su...@apache.org> wrote:
> I am going to release 2.6.0-alpha-4 after 2.5.0 GA is released.
Maybe do another alpha for 3.0 next since I will do a poll on the users list
to see if anyone still needs Parrot on JDK7.
Cheers, Paul.
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: 2.5.0-rc-3
Posted by "Daniel.Sun" <su...@apache.org>.
I am going to release 2.6.0-alpha-4 after 2.5.0 GA is released.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: 2.5.0-rc-3
Posted by Remko Popma <re...@gmail.com>.
Thanks Daniel!
> On May 18, 2018, at 22:00, Daniel.Sun <su...@apache.org> wrote:
>
> FYI
> https://github.com/groovy/groovy-website/blob/master/site/src/site/releasenotes/groovy-2.5.adoc
>
> http://groovy-lang.org/releasenotes/groovy-2.5.html
>
> Cheers,
> Daniel.Sun
>
>
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: 2.5.0-rc-3
Posted by "Daniel.Sun" <su...@apache.org>.
FYI
https://github.com/groovy/groovy-website/blob/master/site/src/site/releasenotes/groovy-2.5.adoc
http://groovy-lang.org/releasenotes/groovy-2.5.html
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: 2.5.0-rc-3
Posted by Remko Popma <re...@gmail.com>.
Where do the release notes live?
I can’t find them on GitHub.
Remko
> On May 18, 2018, at 20:20, Paul King <pa...@asert.com.au> wrote:
>
>
> Last call for changes in rc-3. I hope to prepare the candidate for voting tomorrow.
>
> If all goes well, please then consider the 2_5_X branch semi-frozen. We still want to make changes to fix any bugs etc. but will want extra scrutiny to make sure nothing breaks. There is probably doco changes and such that needs updating too if anyone has some spare cycles, e.g. the 2.5 release notes on the groovy website or any TBDs in the adoc files.
>
> Pending successful voting for rc-3 and then any feedback on the release, the plan will be to release the final version about a week later.
>
> Cheers, Paul.
>
Re: 2.5.0-rc-3
Posted by "Daniel.Sun" <su...@apache.org>.
Try the jitpack
https://github.com/danielsun1106/try-jitpack
Or clone apache/groovy project and run `./gradlew installGroovy` to build
from source and get the snapshot
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: 2.5.0-rc-3
Posted by Paolo Di Tommaso <pa...@gmail.com>.
I'm still experiencing a problem with final variables with 2.5-rc2
https://issues.apache.org/jira/browse/GROOVY-8571
If the rc-3 snapshot is available I would be happy to test it.
p
On Fri, May 18, 2018 at 1:20 PM, Paul King <pa...@asert.com.au> wrote:
>
> Last call for changes in rc-3. I hope to prepare the candidate for voting
> tomorrow.
>
> If all goes well, please then consider the 2_5_X branch semi-frozen. We
> still want to make changes to fix any bugs etc. but will want extra
> scrutiny to make sure nothing breaks. There is probably doco changes and
> such that needs updating too if anyone has some spare cycles, e.g. the 2.5
> release notes on the groovy website or any TBDs in the adoc files.
>
> Pending successful voting for rc-3 and then any feedback on the release,
> the plan will be to release the final version about a week later.
>
> Cheers, Paul.
>
>