[VOTE] Apache Groovy Roadmap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[VOTE] Apache Groovy Roadmap

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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:


BR,
Sergei

On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VOTE] Apache Groovy Roadmap

cchampeau
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 <[hidden email]>:
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:


BR,
Sergei

On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VOTE] Apache Groovy Roadmap

sbglasius
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 <[hidden email]> wrote:
YES for me too (forgot to answer :D). And yes, we should review (and merge) your PR before beta-1.

<a href="tel:20%2017%2001%2031" value="+4520170131" class="gmail_msg" target="_blank">2017-01-31 9:44 GMT+01:00 Sergei Egorov <[hidden email]>:
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:


BR,
Sergei

On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VOTE] Apache Groovy Roadmap

Andres Almiray
In reply to this post by cchampeau
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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VOTE] Apache Groovy Roadmap

Andres Almiray
In reply to this post by sbglasius
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 <[hidden email]> 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 <[hidden email]> wrote:
YES for me too (forgot to answer :D). And yes, we should review (and merge) your PR before beta-1.

<a href="tel:20%2017%2001%2031" value="+4520170131" class="m_8270940681293377734gmail_msg" target="_blank">2017-01-31 9:44 GMT+01:00 Sergei Egorov <[hidden email]>:
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:


BR,
Sergei

On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <[hidden email]> 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: <a href="tel:+45%2040%2044%2091%2088" value="+4540449188" target="_blank">+45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VOTE] Apache Groovy Roadmap

Jochen Theodorou
In reply to this post by cchampeau


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VOTE] Apache Groovy Roadmap

Cédric Champeau


2017-01-31 10:46 GMT+01:00 Jochen Theodorou <[hidden email]>:


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> wrote:


2017-01-31 10:46 GMT+01:00 Jochen Theodorou <[hidden email]>:


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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VOTE] Apache Groovy Roadmap

Jesper Steen Møller
In reply to this post by Jochen Theodorou
On 31 Jan 2017, at 10.46, Jochen Theodorou <[hidden email]> 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
12345
Loading...