Re: release process

[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 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 / 
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: 
http://groovy.329449.n5.nabble.com/release-process-tp5737841p5738247.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: release process

[Guillaume Laforge]

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  wrote:

> 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 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  / 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
> 
>
>
> 

Re: release process

[Paul King]

I have nothing against splitting the currently ear-marked 3.0 into 3
and 4 versions. We need to set expectations within the community when
the time comes and at least for me there are a number of technical
questions that spring to mind around parrot lambda syntax vs Java
lambdas and JDK8 that I think we need to work through in more detail.

On Tue, Jan 31, 2017 at 6:19 PM, Daniel Sun  wrote:
> 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 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 / 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 arch

[VOTE] Apache Groovy Roadmap

[Cédric Champeau]

Hi guys,

There are multiple conversations going on for weeks, and I think they are
going nowhere. We could discuss for months what's the best plan for Groovy,
without releasing anything. Here are the challenges that are waiting for us:

1. release a version of Groovy that integrates Groovy macros
2. upgrade the minimal runtime required for Groovy to 1.7, which is
required to smoothly transition to higher requirements (and also, make our
devs lives easier)
3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
drop the old call site caching and use indy Groovy everywhere
4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
5. compatibility with Jigsaw, aka "Groovy as a module"

I would like to propose the following plan:

- Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
for this for too long
- Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
- Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
changes (we have no choice here)

This plan is, I think, a good compromise for all the requirements we have:
backwards compatibility, and making progress and not having too many
branches. An alternative would be to keep Parrot on Java 8, but as some of
us have said, this is incompatible with a soonish release. The drawback is
that Parrot has the risk of being a breaking change (it is, typically if
people implicitly depend on the old parser, which would be bad), so there's
a risk of not following semantic versioning.

- [ ] YES, I approve the roadmap above
- [ ] NO, I do not approve the roadmap abobe beause...
- [ ] I don't mind, or this goes beyond what I can think of

This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.

Re: [VOTE] Apache Groovy Roadmap

[Sergei Egorov]

YES from me.

Would be great if we can deliver #1 as a macro method, not it form of
"MacroGroovy" (and hopefully forget this awkward name collision :D )

Just want to remind that there is a PR waiting for a review where I rewrote
it and implemented basic macro methods support:
https://github.com/apache/groovy/pull/472/files


BR,
Sergei

On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau 
wrote:

> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>

Re: [VOTE] Apache Groovy Roadmap

[Cédric Champeau]

YES for me too (forgot to answer :D). And yes, we should review (and merge)
your PR before beta-1.

2017-01-31 9:44 GMT+01:00 Sergei Egorov :

> YES from me.
>
> Would be great if we can deliver #1 as a macro method, not it form of
> "MacroGroovy" (and hopefully forget this awkward name collision :D )
>
> Just want to remind that there is a PR waiting for a review where I
> rewrote it and implemented basic macro methods support:
> https://github.com/apache/groovy/pull/472/files
>
>
> BR,
> Sergei
>
> On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau 
> wrote:
>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they are
>> going nowhere. We could discuss for months what's the best plan for Groovy,
>> without releasing anything. Here are the challenges that are waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>> required to smoothly transition to higher requirements (and also, make our
>> devs lives easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>> drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>> for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>> changes (we have no choice here)
>>
>> This plan is, I think, a good compromise for all the requirements we
>> have: backwards compatibility, and making progress and not having too many
>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>> us have said, this is incompatible with a soonish release. The drawback is
>> that Parrot has the risk of being a breaking change (it is, typically if
>> people implicitly depend on the old parser, which would be bad), so there's
>> a risk of not following semantic versioning.
>>
>> - [ ] YES, I approve the roadmap above
>> - [ ] NO, I do not approve the roadmap abobe beause...
>> - [ ] I don't mind, or this goes beyond what I can think of
>>
>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>
>>

Re: [VOTE] Apache Groovy Roadmap

[Søren Berg Glasius]

YES (not binding). This is a clear plan, and is easy to understand for the
community.

It makes way for a 2.5 soon, and it also puts Parrot in a release that is
not too far into the future, which IMO is important.

IMO a good plan.

On Tue, 31 Jan 2017 at 09:45 Cédric Champeau  wrote:

> YES for me too (forgot to answer :D). And yes, we should review (and
> merge) your PR before beta-1.
>
> 2017-01-31 <20%2017%2001%2031> 9:44 GMT+01:00 Sergei Egorov <
> bsid...@gmail.com>:
>
> YES from me.
>
> Would be great if we can deliver #1 as a macro method, not it form of
> "MacroGroovy" (and hopefully forget this awkward name collision :D )
>
> Just want to remind that there is a PR waiting for a review where I
> rewrote it and implemented basic macro methods support:
> https://github.com/apache/groovy/pull/472/files
>
>
> BR,
> Sergei
>
> On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau 
> wrote:
>
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>
> --
Best regards / Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.

Re: [VOTE] Apache Groovy Roadmap

[Andres Almiray]

In principle I'd say YES but I don't agree on Parrot being backported to
2.6 due to potential incompatibilities. I don't want users to have the same
pain we had when switching between Groovy 1.7 and 1.8.
IMHO Parrot should go on 3.x, thus the only parts of the roadmap I can
safely vote YES are #1 and #3. Given the set of voting options we've got my
vote is NO.

My proposed roadmap would be then

- Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
for this for too long
- Groovy 3.0: integrate 3, 4 and 5. The only version with necessary
breaking changes (we have no choice here)

Cheers,
Andres


---
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

On Tue, Jan 31, 2017 at 9:37 AM, Cédric Champeau 
wrote:

> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>

Re: [VOTE] Apache Groovy Roadmap

[Andres Almiray]

Having Parrot available for immediate testing is the reason why I'd
advocate for having 3.0-ea releases ;-)

---
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

On Tue, Jan 31, 2017 at 9:50 AM, Søren Berg Glasius 
wrote:

> YES (not binding). This is a clear plan, and is easy to understand for the
> community.
>
> It makes way for a 2.5 soon, and it also puts Parrot in a release that is
> not too far into the future, which IMO is important.
>
> IMO a good plan.
>
> On Tue, 31 Jan 2017 at 09:45 Cédric Champeau  wrote:
>
>> YES for me too (forgot to answer :D). And yes, we should review (and
>> merge) your PR before beta-1.
>>
>> 2017-01-31 <20%2017%2001%2031> 9:44 GMT+01:00 Sergei Egorov <
>> bsid...@gmail.com>:
>>
>> YES from me.
>>
>> Would be great if we can deliver #1 as a macro method, not it form of
>> "MacroGroovy" (and hopefully forget this awkward name collision :D )
>>
>> Just want to remind that there is a PR waiting for a review where I
>> rewrote it and implemented basic macro methods support:
>> https://github.com/apache/groovy/pull/472/files
>>
>>
>> BR,
>> Sergei
>>
>> On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau 
>> wrote:
>>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they are
>> going nowhere. We could discuss for months what's the best plan for Groovy,
>> without releasing anything. Here are the challenges that are waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>> required to smoothly transition to higher requirements (and also, make our
>> devs lives easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>> drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>> for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>> changes (we have no choice here)
>>
>> This plan is, I think, a good compromise for all the requirements we
>> have: backwards compatibility, and making progress and not having too many
>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>> us have said, this is incompatible with a soonish release. The drawback is
>> that Parrot has the risk of being a breaking change (it is, typically if
>> people implicitly depend on the old parser, which would be bad), so there's
>> a risk of not following semantic versioning.
>>
>> - [ ] YES, I approve the roadmap above
>> - [ ] NO, I do not approve the roadmap abobe beause...
>> - [ ] I don't mind, or this goes beyond what I can think of
>>
>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>
>>
>> --
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>

Re: [VOTE] Apache Groovy Roadmap

[Jochen Theodorou]

On 31.01.2017 09:37, Cédric Champeau wrote:

Hi guys,

There are multiple conversations going on for weeks, and I think they
are going nowhere. We could discuss for months what's the best plan for
Groovy, without releasing anything. Here are the challenges that are
waiting for us:

1. release a version of Groovy that integrates Groovy macros
2. upgrade the minimal runtime required for Groovy to 1.7, which is
required to smoothly transition to higher requirements (and also, make
our devs lives easier)
3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
to drop the old call site caching and use indy Groovy everywhere
4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
5. compatibility with Jigsaw, aka "Groovy as a module"

>

I would like to propose the following plan:

- Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
waiting for this for too long
- Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
- Groovy 3.0: integrate 3 and 5. The only version with necessary
breaking changes (we have no choice here)


If you insist on a removal of antlr2, then this will be a breaking 
change, since we leak antlr2 classes in several places. 2.6 is then only 
an option if antlr2 stays. And considering your earlier statements that 
there should be only one parser, that means 2.6 has to be 3.0.


And considering that there is now a Java7 version of Parrot and that 
there will be at least two major versions before we are on JDK8... why 
not just go with 3.0 right away?


So my -1 based on your argumentation from my side. An alternative plan:

no 2.5
- 3.0 with macro methods and Java7 and parrot
- 4.0 java8 and jigsaw

bye Jochen

Re: [VOTE] Apache Groovy Roadmap

[Cédric Champeau]

2017-01-31 10:46 GMT+01:00 Jochen Theodorou :

>
>
> On 31.01.2017 09:37, Cédric Champeau wrote:
>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they
>> are going nowhere. We could discuss for months what's the best plan for
>> Groovy, without releasing anything. Here are the challenges that are
>> waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>> required to smoothly transition to higher requirements (and also, make
>> our devs lives easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
>> to drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
> >
>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
>> waiting for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary
>> breaking changes (we have no choice here)
>>
>
> If you insist on a removal of antlr2, then this will be a breaking change,
> since we leak antlr2 classes in several places. 2.6 is then only an option
> if antlr2 stays. And considering your earlier statements that there should
> be only one parser, that means 2.6 has to be 3.0.
>
> And considering that there is now a Java7 version of Parrot and that there
> will be at least two major versions before we are on JDK8... why not just
> go with 3.0 right away?
>

Because macro groovy doesn't have to be bound with breaking changes.


>
> So my -1 based on your argumentation from my side. An alternative plan:
>
> no 2.5
> - 3.0 with macro methods and Java7 and parrot
> - 4.0 java8 and jigsaw
>
> bye Jochen
>

Re: [VOTE] Apache Groovy Roadmap

[Alessio Stalla]

Sorry if outsiders are not meant to chime in :)

Why not
 - 2.5 as Cédric proposed (so Java 7 + macros)
 - 3.0 with Java 8 and Parrot
 - 4.0 with Java 9 and Jigsaw?

This way Groovy versions and Java versions are nicely aligned. To let
people try Parrot early, there could be a 3.0 early access release that
only replaces the antlr2-based parser with Parrot and bumps the required
Java version to 8.

On 31 January 2017 at 10:55, Cédric Champeau 
wrote:

>
>
> 2017-01-31 10:46 GMT+01:00 Jochen Theodorou :
>
>>
>>
>> On 31.01.2017 09:37, Cédric Champeau wrote:
>>
>>> Hi guys,
>>>
>>> There are multiple conversations going on for weeks, and I think they
>>> are going nowhere. We could discuss for months what's the best plan for
>>> Groovy, without releasing anything. Here are the challenges that are
>>> waiting for us:
>>>
>>> 1. release a version of Groovy that integrates Groovy macros
>>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>>> required to smoothly transition to higher requirements (and also, make
>>> our devs lives easier)
>>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
>>> to drop the old call site caching and use indy Groovy everywhere
>>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>>
>> >
>>
>>> I would like to propose the following plan:
>>>
>>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
>>> waiting for this for too long
>>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>>> - Groovy 3.0: integrate 3 and 5. The only version with necessary
>>> breaking changes (we have no choice here)
>>>
>>
>> If you insist on a removal of antlr2, then this will be a breaking
>> change, since we leak antlr2 classes in several places. 2.6 is then only an
>> option if antlr2 stays. And considering your earlier statements that there
>> should be only one parser, that means 2.6 has to be 3.0.
>>
>> And considering that there is now a Java7 version of Parrot and that
>> there will be at least two major versions before we are on JDK8... why not
>> just go with 3.0 right away?
>>
>
> Because macro groovy doesn't have to be bound with breaking changes.
>
>
>>
>> So my -1 based on your argumentation from my side. An alternative plan:
>>
>> no 2.5
>> - 3.0 with macro methods and Java7 and parrot
>> - 4.0 java8 and jigsaw
>>
>> bye Jochen
>>
>
>

Re: [VOTE] Apache Groovy Roadmap

[Jesper Steen Møller]

On 31 Jan 2017, at 10.46, Jochen Theodorou  wrote:
> 
> 
> On 31.01.2017 09:37, Cédric Champeau wrote:
>> 
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary
>> breaking changes (we have no choice here)
> 
> If you insist on a removal of antlr2, then this will be a breaking change, 
> since we leak antlr2 classes in several places. 2.6 is then only an option if 
> antlr2 stays. And considering your earlier statements that there should be 
> only one parser, that means 2.6 has to be 3.0.
> 

Were exactly was this leak? The antlr2 classes are jarjar'ed, right - they were 
hardly API. Or am I missing something?
As for usage: A quick search on GitHub for the string 'groovyjarjarantlr' 
revealed 12 commits, most of them in Adempiere and 'groovy-class-parser', in 
pretty old code.

YES to Cedrics proposal (if I'm eligible to vote, that is)

-Jesper

Re: [VOTE] Apache Groovy Roadmap

[Remi Forax]

> De: "Alessio Stalla" 
> À: dev@groovy.apache.org
> Envoyé: Mardi 31 Janvier 2017 11:04:00
> Objet: Re: [VOTE] Apache Groovy Roadmap

> Sorry if outsiders are not meant to chime in :)

> Why not
> - 2.5 as Cédric proposed (so Java 7 + macros)
> - 3.0 with Java 8 and Parrot
> - 4.0 with Java 9 and Jigsaw?

Jigsaw is more or less forward compatible, i.e. you can release jars that will 
use Java 8 to compile (or Java 9 in release mode 8) and also make them jigsaw 
compatible in term of dependencies. 
Obviously the module graph will be read only on Java 9 but the classpath will 
work on Java 8 (and on Java 9). 

> This way Groovy versions and Java versions are nicely aligned. To let people 
> try
> Parrot early, there could be a 3.0 early access release that only replaces the
> antlr2-based parser with Parrot and bumps the required Java version to 8.

Rémi 

> On 31 January 2017 at 10:55, Cédric Champeau < cedric.champ...@gmail.com >
> wrote:

>> 2017-01-31 10:46 GMT+01:00 Jochen Theodorou < blackd...@gmx.org > :

>>> On 31.01.2017 09:37, Cédric Champeau wrote:

 Hi guys,

 There are multiple conversations going on for weeks, and I think they
 are going nowhere. We could discuss for months what's the best plan for
 Groovy, without releasing anything. Here are the challenges that are
 waiting for us:

 1. release a version of Groovy that integrates Groovy macros
 2. upgrade the minimal runtime required for Groovy to 1.7, which is
 required to smoothly transition to higher requirements (and also, make
 our devs lives easier)
 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
 to drop the old call site caching and use indy Groovy everywhere
 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
 5. compatibility with Jigsaw, aka "Groovy as a module"



 I would like to propose the following plan:

 - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
 waiting for this for too long
 - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
 - Groovy 3.0: integrate 3 and 5. The only version with necessary
 breaking changes (we have no choice here)

>>> If you insist on a removal of antlr2, then this will be a breaking change, 
>>> since
>>> we leak antlr2 classes in several places. 2.6 is then only an option if 
>>> antlr2
>>> stays. And considering your earlier statements that there should be only one
>>> parser, that means 2.6 has to be 3.0.

>>> And considering that there is now a Java7 version of Parrot and that there 
>>> will
>>> be at least two major versions before we are on JDK8... why not just go with
>>> 3.0 right away?

>> Because macro groovy doesn't have to be bound with breaking changes.

>>> So my -1 based on your argumentation from my side. An alternative plan:

>>> no 2.5
>>> - 3.0 with macro methods and Java7 and parrot
>>> - 4.0 java8 and jigsaw

>>> bye Jochen

Re: release process

[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 current system, but it should be doable, with a small amount of 
un-diamond'ing.

Java 1.5 is impossble with stock Antlr4, though.

-Jesper

Re: [VOTE] Apache Groovy Roadmap

[Jochen Theodorou]

On 31.01.2017 11:11, Remi Forax wrote:
[...]

Jigsaw is more or less forward compatible, i.e. you can release jars
that will use Java 8  to compile (or Java 9 in release mode 8) and also
make them jigsaw compatible in term of dependencies.
Obviously the module graph will be read only on Java 9 but the classpath
will work on Java 8 (and on Java 9).


Groovy as anonymous module should work right now... at least if you open 
a lot of packages. Groovy as a module is a totally different story, 
because we will basically need the same rights that are right now 
granted to a an anonymous module as normal module, including all the 
dynamic module handling via layers. And adoption of Groovy in a jigsaw 
module world depends on Groovy being able to run as module imho.


The issues we will have under Java9 are mostly these:
(1) setAccessible based logic no longer working, which breaks programs 
that rely on non-public data members from Java classes
(2) URLClassLoader assumption no longer valid breaks all programs using 
@Grab and requiring the systemloader

(3) joint compilation needs to be able to compile a module

I doubt there is going to be a solution for 2, changing 1 will be a huge 
amount of work, since it is not simply done by moving over to 
invokedynamic, the initialization sequence of meta classes will be 
influenced as well. The alternative is dozens of add-opens on the 
command line right now.


And even the solution to that seems to be far fetched... because it 
looks like I will need an agent manipulating every module that comes 
into contact with Groovy to give Groovy extended rights right now.


Number 3 is not even investigated. But of course the biggest piece is 
Groovy as a module itself.


So it is not so much us doing changes that will not work under earlier 
JVMs, it is that there will be a major change in how Groovy behaves as a 
library, because of the restrictions imposed by the module system. And 
that enabling only the slightest bit beyond what we have now, means 
bigger changes in how the MOP works may come. And that is why it is a 
"blow up everything" version


bye Jochen

Re: [VOTE] Apache Groovy Roadmap

[Jochen Theodorou]

[..]

Were exactly was this leak? The antlr2 classes are jarjar'ed, right -
they were hardly API. Or am I missing something?
As for usage: A quick search on GitHub for the string
'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and
'groovy-class-parser', in pretty old code.


I am thinking for example of the groovy-eclipse plugin. Also we do not 
catch all exceptions thrown by antlr afaik.


But maybe I overestimate the problem

bye Jochen

Re: [VOTE] Apache Groovy Roadmap

[Sven Reimers]

I would be volunteering for checking if this is a problem in NetBeans
Groovy Support. What are the patterns I should look for?

Already any branch I could build and try as an experiment?

Thanks

Sven

Am 31.01.2017 12:46 schrieb "Jochen Theodorou" :

> [..]
>
>> Were exactly was this leak? The antlr2 classes are jarjar'ed, right -
>> they were hardly API. Or am I missing something?
>> As for usage: A quick search on GitHub for the string
>> 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and
>> 'groovy-class-parser', in pretty old code.
>>
>
> I am thinking for example of the groovy-eclipse plugin. Also we do not
> catch all exceptions thrown by antlr afaik.
>
> But maybe I overestimate the problem
>
> bye Jochen
>

Re: [VOTE] Apache Groovy Roadmap

[Graeme Rocher]

YES from me.

IMO we should not be waiting until 3.x for Parrot however, I am also
ok with the proposal to change the roadmap so that Groovy 3.x is the
Parrot release and Groovy 4.x the breaking Jigsaw/Java 8/9 release.

The sooner we get folks testing Parrot in the real world the better
and if we wait more it will be a very long time before we see Parrot
or any of the new features used in a project.

Cheers

On Tue, Jan 31, 2017 at 1:46 PM, Sven Reimers  wrote:
> I would be volunteering for checking if this is a problem in NetBeans Groovy
> Support. What are the patterns I should look for?
>
> Already any branch I could build and try as an experiment?
>
> Thanks
>
> Sven
>
> Am 31.01.2017 12:46 schrieb "Jochen Theodorou" :
>>
>> [..]
>>>
>>> Were exactly was this leak? The antlr2 classes are jarjar'ed, right -
>>> they were hardly API. Or am I missing something?
>>> As for usage: A quick search on GitHub for the string
>>> 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and
>>> 'groovy-class-parser', in pretty old code.
>>
>>
>> I am thinking for example of the groovy-eclipse plugin. Also we do not
>> catch all exceptions thrown by antlr afaik.
>>
>> But maybe I overestimate the problem
>>
>> bye Jochen



-- 
Graeme Rocher

Re: New Groovy parser now on JDK 1.7

[Daniel Sun]

Hi Jesper,

 Well done!
 Thanks a lot for your porting Parrot to Java 7 :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/New-Groovy-parser-now-on-JDK-1-7-tp5738237p5738270.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache Groovy Roadmap

[Daniel Sun]

Hi Cédric,

> Because macro groovy doesn't have to be bound with breaking changes.
If program has already used "macro" method name, what will happen?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738271.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache Groovy Roadmap

[Cédric Champeau]

For the beta, it's not super important. For the release I mentioned I
wanted an opt-in mechanism in the past, so it shouldn't be a breaking
change.

2017-01-31 16:33 GMT+01:00 Daniel Sun :

> Hi Cédric,
>
> > Because macro groovy doesn't have to be bound with breaking changes.
> If program has already used "macro" method name, what will happen?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738271.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: release process

[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 the changes are large enough to warrant bumping the 
major version.  However, I see we now have a new thread dedicated to this topic 
so I will continue there.

Keith

> 
> 
> 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 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 > >:
>> 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:
>> >
>> >
>> > 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  / Google+ 
> 

Re: [VOTE] Apache Groovy Roadmap

[Russel Winder]

On Tue, 2017-01-31 at 09:37 +0100, Cédric Champeau wrote:
> […]
> 
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
> 
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.

YES

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: release process

[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.

Having voted YES in the VOTE, which seems to very quickly stop being a
VOTE and turned into a debate, I would be happy with the alternate
proposal (which is not an alternate fact)

From Andres:

- Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
waiting
for this for too long
- Groovy 3.0: integrate 3, 4 and 5. The only version with necessary
breaking changes (we have no choice here)

From Jochen:

no 2.5
- 3.0 with macro methods and Java7 and parrot
- 4.0 java8 and jigsaw

From Alessio:

 - 2.5 as Cédric proposed (so Java 7 + macros)
 - 3.0 with Java 8 and Parrot
 - 4.0 with Java 9 and Jigsaw?

All of these work fine given they ignore the supposed new MOP of Groovy
3 :-)

Remember the first number is always about breaking changes, so lets do
it. Let's break stuff. Then people can put their things back together
and make them better instead of just letting them rot.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Apache Groovy Roadmap

[Bahman Movaqar]

On 01/31/2017 09:37 AM, Cédric Champeau wrote:
> Hi guys,
> 
> There are multiple conversations going on for weeks, and I think they
> are going nowhere. We could discuss for months what's the best plan for
> Groovy, without releasing anything. Here are the challenges that are
> waiting for us:
> 
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make
> our devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
> to drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
> 
> I would like to propose the following plan:
> 
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
> waiting for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary
> breaking changes (we have no choice here)
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of

YES.

Just a side note: Doing 2 in a minor release (2.4 -> 2.5) breaks
backward compatibility --I'd personally rather see such changes in a
major version bump.  On the other hand, JRE6 is (should be) history now,
so this really doesn't matter :-)

--
Bahman Movaqar

http://BahmanM.com - https://twitter.com/bahman__m
https://github.com/bahmanm - https://gist.github.com/bahmanm
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Groovy Roadmap

[Guillaume Laforge]

YES (binding)

On Tue, Jan 31, 2017 at 9:37 AM, Cédric Champeau 
wrote:

> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

Re: [VOTE] Apache Groovy Roadmap

[Suderman Keith]

No.

I would like to vote YES as this is almost what I proposed in the "release 
process" thread, but I think I'm going to have to vote NO as there are 
potential breaking changes in 2.5 (requiring Java 1.7) and 2.6 (switching to 
Parrot).  Hopefully Parrot doesn't break anything, but I don't know if that can 
be asserted definitively at this point.

Keith

> On Jan 31, 2017, at 3:37 AM, Cédric Champeau  wrote:
> 
> Hi guys,
> 
> There are multiple conversations going on for weeks, and I think they are 
> going nowhere. We could discuss for months what's the best plan for Groovy, 
> without releasing anything. Here are the challenges that are waiting for us:
> 
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required 
> to smoothly transition to higher requirements (and also, make our devs lives 
> easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to 
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
> 
> I would like to propose the following plan:
> 
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting for 
> this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking 
> changes (we have no choice here)
> 
> This plan is, I think, a good compromise for all the requirements we have: 
> backwards compatibility, and making progress and not having too many 
> branches. An alternative would be to keep Parrot on Java 8, but as some of us 
> have said, this is incompatible with a soonish release. The drawback is that 
> Parrot has the risk of being a breaking change (it is, typically if people 
> implicitly depend on the old parser, which would be bad), so there's a risk 
> of not following semantic versioning.
> 
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
> 
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
> 

Re: [VOTE] Apache Groovy Roadmap

[Daniel Sun]

Hi  Suderman,

> Hopefully Parrot doesn't break anything, but I don't know if that can be
> asserted definitively at this point.
Parrot passes all tests of Apache Groovy, so it conforms to GLS. In
addition, Parrot can parse source code of Grails, Gradle, Spock, Geb. But I
still hope your program conforms to GLS too ;)

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738282.html
Sent from the Groovy Dev mailing list archive at Nabble.com.