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 <soe...@glasius.dk> 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 <cchamp...@apache.org> 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 <cchamp...@apache.org> >> 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. >
