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 E41C3200C14 for ; Tue, 7 Feb 2017 17:11:33 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id E2B91160B4B; Tue, 7 Feb 2017 16:11:33 +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 1258C160B3E for ; Tue, 7 Feb 2017 17:11:32 +0100 (CET) Received: (qmail 79706 invoked by uid 500); 7 Feb 2017 16:11:31 -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 79696 invoked by uid 99); 7 Feb 2017 16:11:31 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2017 16:11:31 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 2A5E7C0115 for ; Tue, 7 Feb 2017 16:11:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.312 X-Spam-Level: **** X-Spam-Status: No, score=4.312 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URI_HEX=1.313] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id cYEkXxNbos00 for ; Tue, 7 Feb 2017 16:11:28 +0000 (UTC) Received: from homiemail-a81.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id A75BF5F1E9 for ; Tue, 7 Feb 2017 16:11:27 +0000 (UTC) Received: from homiemail-a81.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTP id B0632463D for ; Tue, 7 Feb 2017 08:11:15 -0800 (PST) Received: from new-host.home (pool-173-62-64-171.pghkny.fios.verizon.net [173.62.64.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: keith@suderman.com) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 647D1463B for ; Tue, 7 Feb 2017 08:11:15 -0800 (PST) From: Keith Suderman Content-Type: multipart/alternative; boundary="Apple-Mail=_33BB7DB8-E79C-442C-9D95-B53808CCAFD2" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: [VOTE] Apache Groovy Roadmap Date: Tue, 7 Feb 2017 11:11:14 -0500 References: <1486437503448-5738451.post@n5.nabble.com> <9351CF58-ABE8-4C18-B44F-5178830DC695@selskabet.org> To: dev@groovy.apache.org In-Reply-To: <9351CF58-ABE8-4C18-B44F-5178830DC695@selskabet.org> Message-Id: <036ECC4F-8CCD-4D7C-B86D-5BA10D2A720E@anc.org> X-Mailer: Apple Mail (2.3251) archived-at: Tue, 07 Feb 2017 16:11:34 -0000 --Apple-Mail=_33BB7DB8-E79C-442C-9D95-B53808CCAFD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I will let the PMC decide on the exact numbering and what goes where. = However; +1 on getting Macros and Parrot out the door and available in a 2.x = compatible version as soon as possible. > On Feb 7, 2017, at 9:59 AM, Jesper Steen M=C3=B8ller = wrote: >=20 > Well, I didn't see many actually object to the contents or order that = you suggested, but primarily the numbering. I'll give it another go. >=20 > The vote thread seemed to raise three issues: > 1) Whether or not to provide the parrot parser as a standalone option = ASAP (this is actually quite a bit of work) > 2) How to best design the semantics of lambda expressions in Groovy > 3) How to deal with Groovy in JDK9 with or without breaking changes = (i.e. still support Groovy 2.x in JDK9 WITHOUT Jigsaw, but only Groovy = 3.x WITH Jigsaw, because of indy and new package names, which both break = old classfiles and perhaps source). >=20 > If we're very pedantic about semantic versions, we'll have to bump = major numbers each time we raise the minimum runtime requirement. But - = what if we're less pedantic? We could restate our semantic versioning = interpretation to be that the 2.x line will be source code compatible = with previous 2.x Groovy sources, but with higher JVM runtime = environment requirements. > I.e. you can still run your old Groovy-compiled classfiles with Groovy = 2.x. So they're compatible, you just need a newer runtime... > As for Parrot: It has been backported to 1.7, and while it would = require testing, I can't see the reason for marking it a breaking = change. >=20 > I think we should raise these three discussion points as separate = threads, and restart the vote, but with two flavours: >=20 > YES-1: > - Groovy 2.5: integrates macros and requires Java 7, to be released = ASAP, we've been waiting for this for too long=20 > - Groovy 2.6: integrate Parrot, implying backporting Parrot to Java 7=20= > - Groovy 3.0: integrate Jigsaw and drop old callsite caching + use = indy. The only version with necessary breaking changes (we have no = choice here)=20 > =20 > YES-2: > - Groovy 3.0: integrates macros and requires Java 7, to be released = ASAP, we've been waiting for this for too long=20 > - Groovy 3.1: integrate Parrot, implying backporting Parrot to Java 7=20= > - Groovy 4.0: integrate Jigsaw and drop old callsite caching + use = indy. The only version with necessary breaking changes (we have no = choice here)=20 >=20 > So what will it be:=20 > =20 > - [ ] YES-1, I approve the roadmap with the pragmatic stance to = compatibility=20 > - [ ] YES-2, I approve the roadmap above with the stricter stance = towards compatibility > - [ ] NO, I do not approve the roadmap abobe beause...=20 > - [ ] I don't mind, or this goes beyond what I can think of >=20 > In the end, it's for the PMC to decide. >=20 > -Jesper >=20 >=20 >> On 7 Feb 2017, at 14.15, C=C3=A9dric Champeau = > wrote: >>=20 >> The result is that the vote turned into a debate again. I give up :) >>=20 >> 2017-02-07 4:18 GMT+01:00 Daniel Sun >: >> Hi C=C3=A9dric, >>=20 >> 72h has gone. The result is ? >>=20 >> Cheers, >> Daniel.Sun >>=20 >>=20 >>=20 >> -- >> View this message in context: = http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p57= 38451.html = >> Sent from the Groovy Dev mailing list archive at Nabble.com = . >>=20 >=20 --Apple-Mail=_33BB7DB8-E79C-442C-9D95-B53808CCAFD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I will let the PMC decide on the exact numbering and what = goes where.  However;

+1 on getting Macros and Parrot out the door and available in = a 2.x compatible version as soon as possible.


On Feb 7, 2017, at 9:59 AM, = Jesper Steen M=C3=B8ller <jesper@selskabet.org> wrote:

Well, I didn't = see many actually object to the contents or order that you suggested, but primarily the numbering. = I'll give it another go.

The vote thread seemed to raise three = issues:
1) Whether or not to provide the parrot = parser as a standalone option ASAP (this is actually quite a bit of = work)
2) How to best design the semantics of lambda = expressions in Groovy
3) How to deal with Groovy in = JDK9 with or without breaking changes (i.e. still support Groovy 2.x in = JDK9 WITHOUT Jigsaw, but only Groovy 3.x WITH Jigsaw, because of indy = and new package names, which both break old classfiles and perhaps = source).

If we're very pedantic about semantic versions, we'll have to = bump major numbers each time we raise the minimum runtime requirement. = But - what if we're less pedantic? We could restate our semantic = versioning interpretation to be that the 2.x line will be source code = compatible with previous 2.x Groovy sources, but with higher JVM runtime = environment requirements.
I.e. you can still run = your old Groovy-compiled classfiles with Groovy 2.x. = So they're compatible, you just need a newer runtime...
As for Parrot: It has been backported to 1.7, = and while it would require testing, I can't see the reason for marking = it a breaking change.

I think we should raise these three = discussion points as separate threads, and restart the vote, but with = two flavours:

YES-1:
 - Groovy 2.5: integrates = macros and requires Java 7, to be released ASAP, we've been = waiting for this for too long 
 - Groovy = 2.6: integrate Parrot, implying backporting Parrot to Java 7 
 - Groovy 3.0: integrate Jigsaw and drop old callsite = caching + use indy. The only version with necessary = breaking  changes (we have no choice here) 
 
YES-2:
 -= Groovy 3.0: integrates macros and requires Java 7, to be released ASAP, = we've been waiting for this for too long 
 - = Groovy 3.1: integrate Parrot, implying backporting Parrot to Java = 7 
 - Groovy 4.0: integrate Jigsaw and drop old = callsite caching + use indy. The only version with necessary = breaking  changes (we have no choice here) 

So = what will it be: 
 
 - [ ] = YES-1, I approve the roadmap with the pragmatic stance to = compatibility 
 - [ ] YES-2, I approve the = roadmap above with the stricter stance towards compatibility
 - [ ] NO, I do not approve the roadmap abobe = beause... 
 - [ ] I don't mind, or this goes = beyond what I can think of

In the end, it's for the PMC to decide.

-Jesper


On 7 Feb 2017, at 14.15, C=C3=A9dric Champeau <cedric.champeau@gmail.com> wrote:

The result is that the vote turned into a debate again. I = give up :)

2017-02-07 4:18 GMT+01:00 Daniel Sun <realbluesun@hotmail.com>:
Hi C=C3=A9dric,

        72h has gone.  The result is ?

Cheers,
Daniel.Sun



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



= --Apple-Mail=_33BB7DB8-E79C-442C-9D95-B53808CCAFD2--