From dev-return-4879-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Wed May 23 13:11:24 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 5F99A180645 for ; Wed, 23 May 2018 13:11:24 +0200 (CEST) Received: (qmail 86715 invoked by uid 500); 23 May 2018 11:11:23 -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 86701 invoked by uid 99); 23 May 2018 11:11:22 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 May 2018 11:11:22 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id E1A3A1A0311 for ; Wed, 23 May 2018 11:11:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=selskabet-org.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id ewQEjHTJMx1i for ; Wed, 23 May 2018 11:11:18 +0000 (UTC) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 5525F5F188 for ; Wed, 23 May 2018 11:11:18 +0000 (UTC) Received: by mail-wm0-f41.google.com with SMTP id j4-v6so7899641wme.1 for ; Wed, 23 May 2018 04:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selskabet-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8mT17lv80HRNXMOagW9X0sMEwlaZCoHT6KFTipze/P4=; b=nLdqa3GNwzzv/uRxRZKQWzpzNL1RmpAHPeU+fIDmOXWNSoKyQhNA5k56QBHZDz5+Vs fsWfR2GKNGCpT4fNp4OUcArrbgfdAc3jaafZGyJDNVxKMjEIU2/jXb5BJN+SUu6bZpQV HzY7i8lPp5LGHj+ESu5KoeBoGC0f+x67U0SgkRJ9yxYpx8rFhNgD/aNUrXjwXF2thIIb 7PXvz/mAPqUg6bgOo4Hbx01HJqiOsEqTGi9m069tE2lDKSGmyXo2HCEDfJC2F701a5Q0 j/9XJtZdoXIND1l/6k/nC/lWgpnbzeD+HS0Fl9h3zWFKblu2/aZwlmYk96EZJcE0tFcs hW9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8mT17lv80HRNXMOagW9X0sMEwlaZCoHT6KFTipze/P4=; b=gj48nAyHy7GFbXZHrRSZ+AL9uMJ27rDcNo9TMYXrXBtZm7fwpBg40y/M6JUCfRu84L Pvr3mkopVywJ/aMcR00VZXLGFTVYDTQLXRcrqmbUOZm6LAF1y/GP0CLW1Cnd6/AWFRzH Qj/XOVY0UNheqN+n+aJamEY3xrRS00197ee2oGsJVK2A+C8OsEQfC6ujoQCdN/5AOfjp c8cXaSG07qnigTyAzE/l3x7Hov/HlF0fhUrAg/O42x7T6kJNKxArpbqfZ72iKWZS2GMz 4fq+kswsIhnu8vjW/sNgkg13an6aOY6N8cYR8kMLfBEDttS0sFrcV7F6eaQTsHUydGOz cSFQ== X-Gm-Message-State: ALKqPwdUA48AQNzK2rQxwWa3ifzPl93ISuJl1YOg1EA3xPG0iDqg7Dtw QNG25B61xW05qE5U7w2LG31qjBm+GOc= X-Google-Smtp-Source: AB8JxZoNAZL/p7QgMCmufMkLYpQ3r2fsKdfiINYPuoN7kXzDUKPS2lVqerMgqrJYxpwvr7nfoJsVSA== X-Received: by 2002:a50:a550:: with SMTP id z16-v6mr6649938edb.103.1527073877632; Wed, 23 May 2018 04:11:17 -0700 (PDT) Received: from [192.168.180.33] ([37.49.142.33]) by smtp.gmail.com with ESMTPSA id h51-v6sm10116356eda.88.2018.05.23.04.11.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 04:11:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3] From: =?utf-8?Q?Jesper_Steen_M=C3=B8ller?= In-Reply-To: <987c063231f2c893343e7ec0735e5980d3df8bd7.camel@winder.org.uk> Date: Wed, 23 May 2018 13:11:15 +0200 Cc: paulk@asert.com.au Content-Transfer-Encoding: quoted-printable Message-Id: References: <5b0415be.1c69fb81.1af2b.1078SMTPIN_ADDED_MISSING@mx.google.com> <987c063231f2c893343e7ec0735e5980d3df8bd7.camel@winder.org.uk> To: dev@groovy.apache.org X-Mailer: Apple Mail (2.3273) > On 23 May 2018, at 12.23, Russel Winder wrote: >=20 > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote: >> No plans to go to 18/19 model at this stage. >>=20 >> If we push for an early 3.0, some of the breaking changes will have = to be >> deferred. >> A very quick release after 3.0 could easily be a 3.1 if it was = needed. >>=20 >> The next major release (4.0) would be when we had tackled (a = significant >> chunk of) the remaining breaking changes. >>=20 >=20 > I am not sure a very rapid 3.0 =E2=86=92 3.1 is actually any sort of = problem per se. >=20 > In the current climate is a 3.0 now, 4.0 in the next year actually a = problem? >=20 > Given the very volunteer nature of the Groovy project, pragmatism more = than > anything has to be the order of the day. However I think there is a = marketing > element here. Having new 2.4.X releases doesn't really achieve = anything > marketing-wise. Releasing 2.5.0 actually doesn't much either really, = though > clearly we do it as we are already at RC-3, and it can be "milked". = But 2.5 is > just backward compatible extensions to 2.4, is this Groovy actually > progressing? >=20 > I suggest we want to get a 3.0 out to show Groovy is progressing and = with some > breaking changes, in particular JDK8+ only, not to mention a parser = based on > somewhat newer technology! "Groovy drops support for JDK7" is = probably a good > thing marketing wise. >=20 > My feeling is that Groovy does not have enough resource to go for big = major > version number releases, but that it needs something to combat the = "it's old > technology" feel given the rise of Kotlin. I'd push for a 3.0 release = soon and > worry about the metamodel changes later =E2=80=93 unless they are = already in place? >=20 I agree with the soft factors around numbering. As I understand, the metamodel changes are not in place yet, and not on = anybody's immediate schedule. A) However, as I understand it, MOP2 could be made backwards compatible, = so that a new MOP2 runtime could still honor the MOP1 protocol, from = some version 3.x onwards. We could then deprecate the MOP1 way of doing = things. B) As for the indy stuff, we should choose to produce indy-only = bytecodes now that we require Java 8 for Groovy 3.0. Again, we still = need runtime support for the existing CallSite caching, or we'd have to = force everybody to recompile every Groovy library they use. That's = hardly a good idea! C) Finally, for 3.0 we could switch generation of closures to be = bootstrap-driven, i.e. by keeping the closure body as a method of the = enclosing class, but by generating the closure in the fashion of = LambdaMetafactory. That way, we would keep the Groovy semantics, but = reduce the cost of using closures (all those extra classfiles). We could = possibly introduce a ClosureInterface for forwards compatibility, and = deprecate the use of the Closure class directly. Then, in some future majorversion 4.0, we could stop supporting MOP1, we = could drop support for the old callsite caching, and we could make=20 Was that about right? -Jesper