Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 12C67200C0D for ; Tue, 31 Jan 2017 09:45:40 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 114C2160B52; Tue, 31 Jan 2017 08:45:40 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 35E1B160B46 for ; Tue, 31 Jan 2017 09:45:39 +0100 (CET) Received: (qmail 24411 invoked by uid 500); 31 Jan 2017 08:45:38 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 24401 invoked by uid 99); 31 Jan 2017 08:45:38 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Jan 2017 08:45:38 +0000 Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id EAC911A00A8 for ; Tue, 31 Jan 2017 08:45:37 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id u143so210191070oif.3 for ; Tue, 31 Jan 2017 00:45:37 -0800 (PST) X-Gm-Message-State: AIkVDXIeavmwGqpC+4JKJISon5jqSVuQYSJATYOsau5NSnLE3DzOL/L0wghpPTZuN2A95snTjVWIt5DrlwpGpg== X-Received: by 10.202.81.77 with SMTP id f74mr14510444oib.207.1485852336743; Tue, 31 Jan 2017 00:45:36 -0800 (PST) MIME-Version: 1.0 Reply-To: cchampeau@apache.org Received: by 10.202.193.197 with HTTP; Tue, 31 Jan 2017 00:45:36 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?C=C3=A9dric_Champeau?= Date: Tue, 31 Jan 2017 09:45:36 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [VOTE] Apache Groovy Roadmap To: dev@groovy.apache.org Content-Type: multipart/alternative; boundary=001a113d6a0cb86f1505475ff4be archived-at: Tue, 31 Jan 2017 08:45:40 -0000 --001a113d6a0cb86f1505475ff4be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A9dric Champeau > wrote: > >> Hi guys, >> >> There are multiple conversations going on for weeks, and I think they ar= e >> going nowhere. We could discuss for months what's the best plan for Groo= vy, >> 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 o= ur >> devs lives easier) >> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us t= o >> 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 waitin= g >> 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 breakin= g >> 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 ma= ny >> 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 ther= e'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. >> >> --001a113d6a0cb86f1505475ff4be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
YES for me too (forgot to answer :D). And yes, we should r= eview (and merge) your PR before beta-1.
2017-01-31 9:44 GMT+01:00 Sergei Egorov <bsid= eup@gmail.com>:
YES from me.

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

Ju= st want to remind that there is a PR waiting for a review where I rewrote i= t and implemented basic macro methods support:

=
BR,
Sergei

On Tue, Jan 31,= 2017 at 10:37 AM C=C3=A9dric Champeau <cchampeau@apache.org> wrote:
Hi guys,

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

1. release a version of Groovy that integrates Groovy macr= os
2. upgrade the minima= l runtime required for Groovy to 1.7, which is required to smoothly transit= ion to higher requirements (and also, make our devs lives easier)
3. upgrade the minimal runtime re= quired 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 p= lan:

- Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been wa= iting for this for too long
- Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
<= div class=3D"m_1302086862087156889gmail_msg">- 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 branch= es. An alternative would be to keep Parrot on Java 8, but as some of us hav= e said, this is incompatible with a soonish release. The drawback is that P= arrot has the risk of being a breaking change (it is, typically if people i= mplicitly depend on the old parser, which would be bad), so there's a r= isk of not following semantic versioning.

- [ ] YES, I approve the roadmap ab= ove
- [ ] NO, I do not a= pprove the roadmap abobe beause...
- [ ] I don't mind, or this goes beyond what I can think of<= /div>

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


--001a113d6a0cb86f1505475ff4be--