: [EXT] Re: [DISCUSS] Groovy 5 planning
Hi folks,
We never really resolved a clear direction for our on-going plans in terms of
when to bump our minimum version. There was a poll on twitter back when this
discussion started:
https://urldefense.com/v3/__https://twitter.com/ApacheGroovy/status
ted 5_0_X branch.
>>
>> Thoughts?
>>
>> Cheers, Paul.
>>
>>
>>
>>
>> On Wed, Jul 6, 2022 at 1:44 AM Remi Forax wrote:
>> >
>> > - Original Message -
>> > > From: "Milles, Eric (TR Technology)"
p the version in master to 6 and backport such a
> change onto a newly created 5_0_X branch.
>
> Thoughts?
>
> Cheers, Paul.
>
>
>
>
> On Wed, Jul 6, 2022 at 1:44 AM Remi Forax wrote:
> >
> > - Original Message -
> > > From: "Mi
Milles, Eric (TR Technology)"
> > To: "dev"
> > Sent: Tuesday, July 5, 2022 4:59:52 PM
> > Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning
>
> > I was interested in native interface default/private/static methods
> > (GROOVY-8299, GROOVY-9801, GR
- Original Message -
> From: "Milles, Eric (TR Technology)"
> To: "dev"
> Sent: Tuesday, July 5, 2022 4:59:52 PM
> Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning
> I was interested in native interface default/private/static methods
> (GROOV
/GROOVY-8299
https://issues.apache.org/jira/browse/GROOVY-9801
https://issues.apache.org/jira/browse/GROOVY-1
-Original Message-
From: Daniel Sun
Sent: Sunday, July 3, 2022 1:21 PM
To: dev@groovy.apache.org
Subject: [EXT] Re: [DISCUSS] Groovy 5 planning
External Email: Use caution with
Hi Jochen,
I agree with you. The manpower is always a big problem...
As for the Groovy 5 itself, I wonder what features we should add to the
release. I think following Java's steps is right, but Groovy should have its
own evolving plan. Also, I think polishing Groovy 4 is important to
On 27.06.22 00:04, James Bond wrote:
I think Daniel has a point here. I too have been in FinServ (on the
periphery) for many years, and I know how slow to adopt new standards
organizations like banks can be.
That being said, I would like to suggest two relatively obvious things
to consider:
1
That is exactly what I was thinking: Do not support Java 8 in Groovy 5,
but backport (as has been done in the past) some stuff to
Java8-supporting Groovy 4 G-)
Cheers,
mg
On 27/06/2022 00:04, James Bond wrote:
perhaps an earlier version of Groovy will continue to suffice for them
until they c
I think Daniel has a point here. I too have been in FinServ (on the
periphery) for many years, and I know how slow to adopt new standards
organizations like banks can be.
That being said, I would like to suggest two relatively obvious things
to consider:
1) what's the time frame for Groovy
On 26.06.22 19:39, Daniel Sun wrote:
AFAIK, quite a lot of Groovy users are still using Java 8 because their company
have no plan to upgrade systems to run on Java 9+. It is especially common for
bank systems I have been working on for years, so it's better to continue
supporting Java 8 in Gro
AFAIK, quite a lot of Groovy users are still using Java 8 because their company
have no plan to upgrade systems to run on Java 9+. It is especially common for
bank systems I have been working on for years, so it's better to continue
supporting Java 8 in Groovy 5 releases.
Cheers,
Daniel Sun
On
> From: "Milles, Eric (TR Technology)"
> To: "dev"
> Sent: Wednesday, May 11, 2022 3:29:54 PM
> Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning
> Is there a compelling reason to drop support for Java 8? I don't see it
> holding
> us back quite
T] Re: [DISCUSS] Groovy 5 planning
External Email: Use caution with links and attachments.
I would certainly hope we had Groovy 6 with JDK17 minimum out before JDK11
support was phased out. It might be the case then that Groovy 4 and Groovy 6
are our "sort of LTS" versions at that point.
I would certainly hope we had Groovy 6 with JDK17 minimum out before JDK11
support was phased out. It might be the case then that Groovy 4 and Groovy
6 are our "sort of LTS" versions at that point.
On Wed, May 11, 2022 at 2:22 PM J. David Beutel wrote:
> One thing to consider is the EOL schedule
Comments inline. Basically, I agree other things might push us to JDK17
but I don't see them yet and I am just trying to see if we have consensus
to go to at least JDK11. If so, we can start the work and if we later go to 17
it will be a smaller incremental jump from 11.
On Wed, May 11, 2022 at 5:
On 11.05.22 03:05, Paul King wrote:
Hi folks,
We still have a few things on our TODO list to improve Groovy 4, like
performance and some regressions, but we also need to start planning
for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
begin, so feel free to comment, but I don
One thing to consider is the EOL schedule, of course. Oracle
advertises[1] "extended support" for its Java customers for:
JDK version
until
8
2030*
11
2026
17
2029
* "The Extended Support uplift fee will be waived for the period March
2022 - December 2030 for
Hi folks,
We still have a few things on our TODO list to improve Groovy 4, like
performance and some regressions, but we also need to start planning
for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
begin, so feel free to comment, but I don't expect many of us will
have time to
19 matches
Mail list logo
