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 E7AFA200C0D for ; Tue, 31 Jan 2017 18:09:48 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id E65C7160B52; Tue, 31 Jan 2017 17:09:48 +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 6B15E160B36 for ; Tue, 31 Jan 2017 18:09:47 +0100 (CET) Received: (qmail 90497 invoked by uid 500); 31 Jan 2017 17:09:46 -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 90487 invoked by uid 99); 31 Jan 2017 17:09:46 -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, 31 Jan 2017 17:09:46 +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 EE374C0096 for ; Tue, 31 Jan 2017 17:09:45 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.499 X-Spam-Level: *** X-Spam-Status: No, score=3.499 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, RCVD_IN_SORBS_SPAM=0.5] 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 XsCxRo4xka79 for ; Tue, 31 Jan 2017 17:09:43 +0000 (UTC) Received: from homiemail-a45.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 E49265FAD8 for ; Tue, 31 Jan 2017 17:09:42 +0000 (UTC) Received: from homiemail-a45.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a45.g.dreamhost.com (Postfix) with ESMTP id 343996430 for ; Tue, 31 Jan 2017 09:09:41 -0800 (PST) Received: from [129.64.177.69] (unknown [129.64.177.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: keith@suderman.com) by homiemail-a45.g.dreamhost.com (Postfix) with ESMTPSA id C841D642F for ; Tue, 31 Jan 2017 09:09:40 -0800 (PST) From: Suderman Keith Content-Type: multipart/alternative; boundary="Apple-Mail=_089B44EC-FA5A-4B55-8C92-C708DE5CFB09" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: release process Date: Tue, 31 Jan 2017 12:09:39 -0500 References: <5880C018.3070204@gmx.org> <5882505D.1090304@gmx.org> <29E34952-6E24-4AC5-BA5D-A5304468285C@anc.org> To: dev@groovy.apache.org In-Reply-To: Message-Id: <6E5FE78E-A490-4D71-931C-61611CDB96B5@anc.org> X-Mailer: Apple Mail (2.3251) archived-at: Tue, 31 Jan 2017 17:09:49 -0000 --Apple-Mail=_089B44EC-FA5A-4B55-8C92-C708DE5CFB09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 30, 2017, at 3:32 PM, Guillaume Laforge = wrote: >=20 > That's indeed another approach. > But that would mean two close major releases with breaking changes. Do = you think it'd be acceptable? Yes, particularly since the 3.0 release wouldn't (hopefully) really = break anything, I just think the changes are large enough to warrant = bumping the major version. However, I see we now have a new thread = dedicated to this topic so I will continue there. Keith >=20 >=20 > On Mon, Jan 30, 2017 at 7:37 PM, Suderman Keith > wrote: >=20 >> On Jan 24, 2017, at 9:51 AM, C=C3=A9dric Champeau = > wrote: >>=20 >> The main problem is parrot is that it requires Java 8, and 2.5 is = planned to support 1.7. And bundling such a core thing as an = experimental, optional module is a no-go for me (imagine the bug = reports...). We could have a 2.9 release (or something similar) with = Parrot sooner, though. >=20 > Maybe it is time to rethink the Groovy roadmap with respect to version = numbers? For example, something like >=20 > 2.x Continue as is > 3.x Java 1.7 + Parrot. Maintain binary compatibility as much as = possible. (was 2.9) > 4.x Java 1.8 + Parrot + Jigsaw (was 3.0) >=20 > This would make 4.x the new "blow up everything" release. Personally = I consider a move from Java 1.7 -> Java 1.8 a breaking change and should = not be done in a 2.x release. This roadmap would clearly separate = upgrades and breaking changes while still allowing people to start using = Parrot in what is essentially 2.x as soon as possible. >=20 > Cheers, > Keith >=20 >>=20 >> (as a side note, any release of Groovy that would require Java 8 = would be a no-go for Gradle in short term, be it 2.x or 3.x) >>=20 >> 2017-01-24 15:45 GMT+01:00 Graeme Rocher >: >> Understood. >>=20 >> I still think it would be valuable to have a Parrot + Java 8 + Groovy >> 2.x release before Groovy 3.x >>=20 >> Maybe I am alone here, but it seems a shame that actual users won't >> get to benefit from Parrot for quite a few years. >>=20 >> Cheers >>=20 >> On Tue, Jan 24, 2017 at 3:03 PM, Jochen Theodorou > wrote: >> > >> > >> > On 24.01.2017 14:50, Graeme Rocher wrote: >> >> >> >> Is the plan for 3.0 to break binary compatibility for existing = libraries? >> >> >> >> Personally I don't think we should ever have a version that we = call >> >> "blow everything up version" that would be a big red flag for me. >> >> Imagine Oracle announcing the Java JDK "blow everything up" = edition. >> > >> > >> > you mean like Java9 with jigsaw? >> > >> >> Is there a way to retain some form of binary compatibility maybe >> >> through `groovy-compat` that contains the old call site caching? >> > >> > >> > That depends. If we want to change Closure to be a functional = interface for >> > example, then not really. groovy-compat would have to transform the = code >> > using Groovy. Or we have a transform that will force the program to = use the >> > old closures, then we can still solve the issue. >> > >> > In other words, I think we should develop freely till we have what = we want >> > and then think about how to make things compatible again. >> > >> > bye Jochen >>=20 >>=20 >>=20 >> -- >> Graeme Rocher >>=20 >=20 >=20 >=20 >=20 > --=20 > Guillaume Laforge > Apache Groovy committer & PMC Vice-President > Developer Advocate @ Google Cloud Platform >=20 > Blog: http://glaforge.appspot.com/ > Social: @glaforge / Google+ = --Apple-Mail=_089B44EC-FA5A-4B55-8C92-C708DE5CFB09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 30, 2017, at 3:32 PM, Guillaume Laforge <glaforge@gmail.com> = wrote:

That's indeed another approach.
But = that would mean two close major releases with breaking changes. Do you = think it'd be acceptable?

Yes, particularly since the 3.0 release wouldn't = (hopefully) really break anything, I just think the changes are large = enough to warrant bumping the major version.  However, I see we now = have a new thread dedicated to this topic so I will continue = there.

Keith



On Mon, = Jan 30, 2017 at 7:37 PM, Suderman Keith <suderman@anc.org> wrote:

On Jan 24, 2017, at 9:51 AM, C=C3=A9dric Champeau <cedric.champeau@gmail.com> wrote:

The main problem is parrot is = that it requires Java 8, and 2.5 is planned to support 1.7. And bundling = such a core thing as an experimental, optional module is a no-go for me = (imagine the bug reports...). We could have a 2.9 release (or something = similar) with Parrot sooner, though.

Maybe it is time to rethink the = Groovy roadmap with respect to version numbers?  For example, = something like

2.x Continue as is
3.x Java 1.7 + = Parrot.  Maintain binary compatibility as much as possible. (was = 2.9)
4.x Java 1.8 + Parrot + Jigsaw (was = 3.0)

This = would make 4.x the new "blow up everything" release.  Personally I = consider a move from Java 1.7 -> Java 1.8 a breaking change and = should not be done in a 2.x release.  This roadmap would clearly = separate upgrades and breaking changes while still allowing people to = start using Parrot in what is essentially 2.x as soon as = possible.

Cheers,
Keith

(as a side note, any release of Groovy = that would require Java 8 would be a no-go for Gradle in short term, be = it 2.x or 3.x)

2017-01-24 15:45 GMT+01:00 Graeme Rocher <graeme.rocher@gmail.com>:
Understood.

I still think it would be valuable to have a Parrot + Java 8 + Groovy
2.x release before Groovy 3.x

Maybe I am alone here, but it seems a shame that actual users won't
get to benefit from Parrot for quite a few years.

Cheers

On Tue, Jan 24, 2017 at 3:03 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:
>
>
> On 24.01.2017 14:50, Graeme Rocher wrote:
>>
>> Is the plan for 3.0 to break binary compatibility for existing = libraries?
>>
>> Personally I don't think we should ever have a version that we = call
>> "blow everything up version" that would be a big red flag for = me.
>> Imagine Oracle announcing the Java JDK "blow everything up" = edition.
>
>
> you mean like Java9 with jigsaw?
>
>> Is there a way to retain some form of binary compatibility = maybe
>> through `groovy-compat` that contains the old call site = caching?
>
>
> That depends. If we want to change Closure to be a functional = interface for
> example, then not really. groovy-compat would have to transform the = code
> using Groovy. Or we have a transform that will force the program to = use the
> old closures, then we can still solve the issue.
>
> In other words, I think we should develop freely till we have what = we want
> and then think about how to make things compatible again.
>
> bye Jochen



--
Graeme Rocher





--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge / Google+

= --Apple-Mail=_089B44EC-FA5A-4B55-8C92-C708DE5CFB09--