That makes sense to me. On Tue, Aug 9, 2022 at 5:19 AM Guillaume Laforge <glafo...@gmail.com> wrote:
> The variant sounds pragmatic to me. > > Guillaume > > > Le lun. 8 août 2022, 13:24, Paul King <pa...@asert.com.au> a écrit : > >> 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://twitter.com/ApacheGroovy/status/1524255310923595776 >> >> That shows a keen interest in bumping up our minimum version but still >> a reasonable percentage of folks wanting the status quo. >> >> The two obvious choices are: >> (1) Stick with JDK8 for Groovy 5 and bump for Groovy 6 - the >> implications being we defer numerous activities that depend on the >> bump or branch off Groovy 6 earlier rather than later. The downside in >> having many branches is that it increases our load when >> cherry-picking/porting fixes across branches. >> (2) Lock in JDK11 for Groovy 5 (we spoke of potentially jumping to >> JDK17 if a compelling reason pushed us in that direction - but so far >> there hasn't been such a reason, so I am suggesting we defer that part >> of the decision for now). This means that bigger changes for JDK8 >> might cause 4.1, 4.2, 4.x branches in the future. >> >> I'd like to suggest a variant of (2). We start off by bumping master >> to JDK11. If, before we release Groovy 5, we do end up with a bigger >> change appearing that might be nice to push back to JDK8, we reserve >> the right to bump 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 <fo...@univ-mlv.fr> wrote: >> > >> > ----- Original Message ----- >> > > From: "Milles, Eric (TR Technology)" <eric.mil...@thomsonreuters.com> >> > > To: "dev" <dev@groovy.apache.org> >> > > 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, GROOVY-10000) for Groovy 5. There was >> discussion on >> > > what was needed for this at one point. Does anyone remember if Java >> 8 was >> > > holding us back in this area? >> > >> > It does not, Java the language only adds interface private methods in >> Java 9 but the VM already supports them since 8. >> > >> > As a trivia, the support in the VM was added in 8 to be able to desugar >> the body of a lambda as a private method (static or not) when a lambda is >> used inside a default method. >> > >> > > >> > > https://issues.apache.org/jira/browse/GROOVY-8299 >> > > https://issues.apache.org/jira/browse/GROOVY-9801 >> > > https://issues.apache.org/jira/browse/GROOVY-10000 >> > >> > regards, >> > Rémi >> > >> > > >> > > >> > > -----Original Message----- >> > > From: Daniel Sun <sun...@apache.org> >> > > 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 links and attachments. >> > > >> > > 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 too, >> e.g. fixing >> > > issues and improving performance. >> > > >> > > Cheers, >> > > Daniel Sun >> > > On 2022/06/26 21:55:33 Jochen Theodorou wrote: >> > >> 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 Groovy 5 releases. >> > >> >> > >> When is it likely for them to change? If we go by the Oracle extended >> > >> support it would mean to have Java8 in till 2030. >> > >> >> > >> if we had the manpower I would suggest making a java8 version of >> > >> Groovy 5. But I think that is not realistic. It will be difficult to >> > >> support deprecated/removed API. I mean it is a bit more than in the >> > >> past where it was about backporting features to older Java versions >> or >> > >> enabling language only features on older Java versions. The >> > >> alternative would then be to not to support that feature anymore... >> > >> like for example the SecurityManager. But would such a Groovy-Version >> > >> still be useful in its current usage? >> > >> >> > >> >> > >> bye Jochen >> >
