[VOTE][LAZY] Apache Groovy Roadmap - take 2

[Paul King <pa...@asert.com.au>]

Hi folks,

Earlier in the year, Cédric did a great job of outlining a possible
roadmap for Groovy. I think there was general consensus on most of it
but we never quite managed complete consensus.

We had a fairly clear consensus on getting out 2.5 with macro support
- that is underway now.

There was also consensus around a version of Groovy containing the new
parrot parser and based around a minimum JDK runtime requirement of
1.8 (possibly numbered Groovy 3.0 or 4.0). This is what we'll start
fleshing out on the master branch.

I believe there was also general consensus around a version of Groovy
containing a back-ported version of the parrot parser for jdk 1.7
(possibly numbered Groovy 2.6 or 3.0).

The main contention seemed to be what level of breaking changes (if
any) should be allowed in a 2.6 release (vs 3.0 release) etc. I don't
believe there was a serious divide in opinions, just that without some
more concrete details about what would actually be in any of the
various proposed releases, it was difficult to zero in on a final
roadmap.

Rather than continue debate at a theoretical level about the roadmap,
I plan to just start fleshing out some more details of the potential
releases and we can decide when to release and what to call them once
they are fleshed out further.

With this in mind, I plan to create a 2_6_X branch. The intention will
be to try out the back-ported parrot to convince ourselves if any
(significant) breaking changes have been introduced - and
(potentially) exclude some of Parrot's changes. This branch can be
considered a bridging version of Groovy for JDK 1.7 users who can't go
straight to the full 1.8 based version. We can decide later whether
this branch forms the basis of a 2.6, 3.0 or no release.

This is a lazy consensus vote, so I'll go ahead and create the branch
in 72 hrs for the purposes described above unless I hear serious
objections.

Cheers, Paul.

Re: [VOTE][LAZY] Apache Groovy Roadmap - take 2

[Andres Almiray <aa...@gmail.com>]

+1 Thanks Paul!

Sent from my primitive Tricorder

> On 16 Mar 2017, at 17:23, Mario Garcia <ma...@gmail.com> wrote:
> 
> +1
> 
>> On 16 Mar 2017 15:29, "Guillaume Laforge" <gl...@gmail.com> wrote:
>> +1
>> 
>>> On Wed, Mar 15, 2017 at 4:15 AM, Paul King <pa...@asert.com.au> wrote:
>>> Hi folks,
>>> 
>>> Earlier in the year, Cédric did a great job of outlining a possible
>>> roadmap for Groovy. I think there was general consensus on most of it
>>> but we never quite managed complete consensus.
>>> 
>>> We had a fairly clear consensus on getting out 2.5 with macro support
>>> - that is underway now.
>>> 
>>> There was also consensus around a version of Groovy containing the new
>>> parrot parser and based around a minimum JDK runtime requirement of
>>> 1.8 (possibly numbered Groovy 3.0 or 4.0). This is what we'll start
>>> fleshing out on the master branch.
>>> 
>>> I believe there was also general consensus around a version of Groovy
>>> containing a back-ported version of the parrot parser for jdk 1.7
>>> (possibly numbered Groovy 2.6 or 3.0).
>>> 
>>> The main contention seemed to be what level of breaking changes (if
>>> any) should be allowed in a 2.6 release (vs 3.0 release) etc. I don't
>>> believe there was a serious divide in opinions, just that without some
>>> more concrete details about what would actually be in any of the
>>> various proposed releases, it was difficult to zero in on a final
>>> roadmap.
>>> 
>>> Rather than continue debate at a theoretical level about the roadmap,
>>> I plan to just start fleshing out some more details of the potential
>>> releases and we can decide when to release and what to call them once
>>> they are fleshed out further.
>>> 
>>> With this in mind, I plan to create a 2_6_X branch. The intention will
>>> be to try out the back-ported parrot to convince ourselves if any
>>> (significant) breaking changes have been introduced - and
>>> (potentially) exclude some of Parrot's changes. This branch can be
>>> considered a bridging version of Groovy for JDK 1.7 users who can't go
>>> straight to the full 1.8 based version. We can decide later whether
>>> this branch forms the basis of a 2.6, 3.0 or no release.
>>> 
>>> This is a lazy consensus vote, so I'll go ahead and create the branch
>>> in 72 hrs for the purposes described above unless I hear serious
>>> objections.
>>> 
>>> Cheers, Paul.
>> 
>> 
>> 
>> -- 
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>> 
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+

Re: [VOTE][LAZY] Apache Groovy Roadmap - take 2

[Mario Garcia <ma...@gmail.com>]

+1

On 16 Mar 2017 15:29, "Guillaume Laforge" <gl...@gmail.com> wrote:

> +1
>
> On Wed, Mar 15, 2017 at 4:15 AM, Paul King <pa...@asert.com.au> wrote:
>
>> Hi folks,
>>
>> Earlier in the year, Cédric did a great job of outlining a possible
>> roadmap for Groovy. I think there was general consensus on most of it
>> but we never quite managed complete consensus.
>>
>> We had a fairly clear consensus on getting out 2.5 with macro support
>> - that is underway now.
>>
>> There was also consensus around a version of Groovy containing the new
>> parrot parser and based around a minimum JDK runtime requirement of
>> 1.8 (possibly numbered Groovy 3.0 or 4.0). This is what we'll start
>> fleshing out on the master branch.
>>
>> I believe there was also general consensus around a version of Groovy
>> containing a back-ported version of the parrot parser for jdk 1.7
>> (possibly numbered Groovy 2.6 or 3.0).
>>
>> The main contention seemed to be what level of breaking changes (if
>> any) should be allowed in a 2.6 release (vs 3.0 release) etc. I don't
>> believe there was a serious divide in opinions, just that without some
>> more concrete details about what would actually be in any of the
>> various proposed releases, it was difficult to zero in on a final
>> roadmap.
>>
>> Rather than continue debate at a theoretical level about the roadmap,
>> I plan to just start fleshing out some more details of the potential
>> releases and we can decide when to release and what to call them once
>> they are fleshed out further.
>>
>> With this in mind, I plan to create a 2_6_X branch. The intention will
>> be to try out the back-ported parrot to convince ourselves if any
>> (significant) breaking changes have been introduced - and
>> (potentially) exclude some of Parrot's changes. This branch can be
>> considered a bridging version of Groovy for JDK 1.7 users who can't go
>> straight to the full 1.8 based version. We can decide later whether
>> this branch forms the basis of a 2.6, 3.0 or no release.
>>
>> This is a lazy consensus vote, so I'll go ahead and create the branch
>> in 72 hrs for the purposes described above unless I hear serious
>> objections.
>>
>> Cheers, Paul.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Re: [VOTE][LAZY] Apache Groovy Roadmap - take 2

[Guillaume Laforge <gl...@gmail.com>]

+1

On Wed, Mar 15, 2017 at 4:15 AM, Paul King <pa...@asert.com.au> wrote:

> Hi folks,
>
> Earlier in the year, Cédric did a great job of outlining a possible
> roadmap for Groovy. I think there was general consensus on most of it
> but we never quite managed complete consensus.
>
> We had a fairly clear consensus on getting out 2.5 with macro support
> - that is underway now.
>
> There was also consensus around a version of Groovy containing the new
> parrot parser and based around a minimum JDK runtime requirement of
> 1.8 (possibly numbered Groovy 3.0 or 4.0). This is what we'll start
> fleshing out on the master branch.
>
> I believe there was also general consensus around a version of Groovy
> containing a back-ported version of the parrot parser for jdk 1.7
> (possibly numbered Groovy 2.6 or 3.0).
>
> The main contention seemed to be what level of breaking changes (if
> any) should be allowed in a 2.6 release (vs 3.0 release) etc. I don't
> believe there was a serious divide in opinions, just that without some
> more concrete details about what would actually be in any of the
> various proposed releases, it was difficult to zero in on a final
> roadmap.
>
> Rather than continue debate at a theoretical level about the roadmap,
> I plan to just start fleshing out some more details of the potential
> releases and we can decide when to release and what to call them once
> they are fleshed out further.
>
> With this in mind, I plan to create a 2_6_X branch. The intention will
> be to try out the back-ported parrot to convince ourselves if any
> (significant) breaking changes have been introduced - and
> (potentially) exclude some of Parrot's changes. This branch can be
> considered a bridging version of Groovy for JDK 1.7 users who can't go
> straight to the full 1.8 based version. We can decide later whether
> this branch forms the basis of a 2.6, 3.0 or no release.
>
> This is a lazy consensus vote, so I'll go ahead and create the branch
> in 72 hrs for the purposes described above unless I hear serious
> objections.
>
> Cheers, Paul.
>



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

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Re: [VOTE][LAZY] Apache Groovy Roadmap - take 2

[Graeme Rocher <gr...@gmail.com>]

+1

On Thu, Mar 16, 2017 at 10:36 PM, Jochen Theodorou <bl...@gmx.org> wrote:
> if that means not waiting another year for parrot: +1
>
>
> On 15.03.2017 04:15, Paul King wrote:
>>
>> Hi folks,
>>
>> Earlier in the year, Cédric did a great job of outlining a possible
>> roadmap for Groovy. I think there was general consensus on most of it
>> but we never quite managed complete consensus.
>>
>> We had a fairly clear consensus on getting out 2.5 with macro support
>> - that is underway now.
>>
>> There was also consensus around a version of Groovy containing the new
>> parrot parser and based around a minimum JDK runtime requirement of
>> 1.8 (possibly numbered Groovy 3.0 or 4.0). This is what we'll start
>> fleshing out on the master branch.
>>
>> I believe there was also general consensus around a version of Groovy
>> containing a back-ported version of the parrot parser for jdk 1.7
>> (possibly numbered Groovy 2.6 or 3.0).
>>
>> The main contention seemed to be what level of breaking changes (if
>> any) should be allowed in a 2.6 release (vs 3.0 release) etc. I don't
>> believe there was a serious divide in opinions, just that without some
>> more concrete details about what would actually be in any of the
>> various proposed releases, it was difficult to zero in on a final
>> roadmap.
>>
>> Rather than continue debate at a theoretical level about the roadmap,
>> I plan to just start fleshing out some more details of the potential
>> releases and we can decide when to release and what to call them once
>> they are fleshed out further.
>>
>> With this in mind, I plan to create a 2_6_X branch. The intention will
>> be to try out the back-ported parrot to convince ourselves if any
>> (significant) breaking changes have been introduced - and
>> (potentially) exclude some of Parrot's changes. This branch can be
>> considered a bridging version of Groovy for JDK 1.7 users who can't go
>> straight to the full 1.8 based version. We can decide later whether
>> this branch forms the basis of a 2.6, 3.0 or no release.
>>
>> This is a lazy consensus vote, so I'll go ahead and create the branch
>> in 72 hrs for the purposes described above unless I hear serious
>> objections.
>>
>> Cheers, Paul.
>>
>



-- 
Graeme Rocher

Re: [VOTE][LAZY] Apache Groovy Roadmap - take 2

[Jochen Theodorou <bl...@gmx.org>]

if that means not waiting another year for parrot: +1

On 15.03.2017 04:15, Paul King wrote:
> Hi folks,
>
> Earlier in the year, C�dric did a great job of outlining a possible
> roadmap for Groovy. I think there was general consensus on most of it
> but we never quite managed complete consensus.
>
> We had a fairly clear consensus on getting out 2.5 with macro support
> - that is underway now.
>
> There was also consensus around a version of Groovy containing the new
> parrot parser and based around a minimum JDK runtime requirement of
> 1.8 (possibly numbered Groovy 3.0 or 4.0). This is what we'll start
> fleshing out on the master branch.
>
> I believe there was also general consensus around a version of Groovy
> containing a back-ported version of the parrot parser for jdk 1.7
> (possibly numbered Groovy 2.6 or 3.0).
>
> The main contention seemed to be what level of breaking changes (if
> any) should be allowed in a 2.6 release (vs 3.0 release) etc. I don't
> believe there was a serious divide in opinions, just that without some
> more concrete details about what would actually be in any of the
> various proposed releases, it was difficult to zero in on a final
> roadmap.
>
> Rather than continue debate at a theoretical level about the roadmap,
> I plan to just start fleshing out some more details of the potential
> releases and we can decide when to release and what to call them once
> they are fleshed out further.
>
> With this in mind, I plan to create a 2_6_X branch. The intention will
> be to try out the back-ported parrot to convince ourselves if any
> (significant) breaking changes have been introduced - and
> (potentially) exclude some of Parrot's changes. This branch can be
> considered a bridging version of Groovy for JDK 1.7 users who can't go
> straight to the full 1.8 based version. We can decide later whether
> this branch forms the basis of a 2.6, 3.0 or no release.
>
> This is a lazy consensus vote, so I'll go ahead and create the branch
> in 72 hrs for the purposes described above unless I hear serious
> objections.
>
> Cheers, Paul.
>