You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@grails.apache.org by James Fredley <ja...@apache.org> on 2026/10/07 15:56:47 UTC
[DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Hi all,
This is a follow-up to the earlier thread and to today's weekly meeting.
This is a discuss thread, not a vote. The goal is to settle the language
for a follow-up [VOTE] on the next several Grails lines.
Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
has already started: https://github.com/apache/groovy
Please comment on the plan and on the wording. If you want to change the
language, copy the whole proposal block below, paste it into your reply,
and edit it there. Do not send a partial rewrite or a diff of a
sentence. A full replacement block is what we will carry into the vote.
If you agree with the block as written, a +1 on this thread is enough.
Discussion on this thread is not a binding vote.
PROPOSAL (copy this whole block if you want to change the language)
1. Grails 9.0.x
1. Merge the 8.1.x branch up into the 9.0.x branch.
2. Do not release 8.1.x. Skip that line.
3. Ship 9.0.x as a lighter release: bring Grails current with
Groovy, without waiting on the next Spring Boot line.
4. Base it on Groovy 6.
5. Turn invokedynamic on.
1. Turning invokedynamic off is not a viable default. In Groovy
6.0.0 the classic call-site implementation has moved out of groovy-core
into the separate groovy-callsite module, and that surface is on a path
to deprecation. Core dispatch already uses invokedynamic.
6. Target 9.0.0 for the end of November 2026.
7. This release catches Grails up to Groovy. Apache Groovy 7 work
has already started: https://github.com/apache/groovy
2. Grails 10 (the line previously discussed as 9.1.x)
1. Rename the planned 9.1.x line to 10.
2. Base it on Groovy 6 and Spring Boot 4.2.
3. Target 2027 Q1. Aim to release within one month of Spring Boot
4.2. That window is tight because of existing time commitments.
4. Use the major version bump so the release can carry material
breaking changes and move the framework forward.
James
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by Walter Duque de Estrada via dev <de...@grails.apache.org>.
When would you tackle the current G9 branches, move them to 10?
Walter
Sent from my iPhone
> On Oct 7, 2026, at 12:48 PM, James Daugherty via dev <de...@grails.apache.org> wrote:
>
> For #1, I think the only addition is we would ship the 2 PRs from scott on
> 4.1 related to Json changes in 9.0. Otherwise, no other major changes
> other than possibly forge conversion & what's in 8.1 already.
>
> Otherwise, I'm +1 for this.
>
>
>
>> On Wed, Oct 7, 2026 at 11:57 AM James Fredley <ja...@apache.org>
>> wrote:
>>
>> Hi all,
>>
>> This is a follow-up to the earlier thread and to today's weekly meeting.
>> This is a discuss thread, not a vote. The goal is to settle the language
>> for a follow-up [VOTE] on the next several Grails lines.
>>
>> Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
>> already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
>> has already started: https://github.com/apache/groovy
>>
>> Please comment on the plan and on the wording. If you want to change the
>> language, copy the whole proposal block below, paste it into your reply,
>> and edit it there. Do not send a partial rewrite or a diff of a
>> sentence. A full replacement block is what we will carry into the vote.
>> If you agree with the block as written, a +1 on this thread is enough.
>> Discussion on this thread is not a binding vote.
>>
>> PROPOSAL (copy this whole block if you want to change the language)
>>
>> 1. Grails 9.0.x
>> 1. Merge the 8.1.x branch up into the 9.0.x branch.
>> 2. Do not release 8.1.x. Skip that line.
>> 3. Ship 9.0.x as a lighter release: bring Grails current with
>> Groovy, without waiting on the next Spring Boot line.
>> 4. Base it on Groovy 6.
>> 5. Turn invokedynamic on.
>> 1. Turning invokedynamic off is not a viable default. In Groovy
>> 6.0.0 the classic call-site implementation has moved out of groovy-core
>> into the separate groovy-callsite module, and that surface is on a path
>> to deprecation. Core dispatch already uses invokedynamic.
>> 6. Target 9.0.0 for the end of November 2026.
>> 7. This release catches Grails up to Groovy. Apache Groovy 7 work
>> has already started: https://github.com/apache/groovy
>>
>> 2. Grails 10 (the line previously discussed as 9.1.x)
>> 1. Rename the planned 9.1.x line to 10.
>> 2. Base it on Groovy 6 and Spring Boot 4.2.
>> 3. Target 2027 Q1. Aim to release within one month of Spring Boot
>> 4.2. That window is tight because of existing time commitments.
>> 4. Use the major version bump so the release can carry material
>> breaking changes and move the framework forward.
>>
>>
>> James
>>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Daugherty via dev <de...@grails.apache.org>.
For #1, I think the only addition is we would ship the 2 PRs from scott on
4.1 related to Json changes in 9.0. Otherwise, no other major changes
other than possibly forge conversion & what's in 8.1 already.
Otherwise, I'm +1 for this.
On Wed, Oct 7, 2026 at 11:57 AM James Fredley <ja...@apache.org>
wrote:
> Hi all,
>
> This is a follow-up to the earlier thread and to today's weekly meeting.
> This is a discuss thread, not a vote. The goal is to settle the language
> for a follow-up [VOTE] on the next several Grails lines.
>
> Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
> already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
> has already started: https://github.com/apache/groovy
>
> Please comment on the plan and on the wording. If you want to change the
> language, copy the whole proposal block below, paste it into your reply,
> and edit it there. Do not send a partial rewrite or a diff of a
> sentence. A full replacement block is what we will carry into the vote.
> If you agree with the block as written, a +1 on this thread is enough.
> Discussion on this thread is not a binding vote.
>
> PROPOSAL (copy this whole block if you want to change the language)
>
> 1. Grails 9.0.x
> 1. Merge the 8.1.x branch up into the 9.0.x branch.
> 2. Do not release 8.1.x. Skip that line.
> 3. Ship 9.0.x as a lighter release: bring Grails current with
> Groovy, without waiting on the next Spring Boot line.
> 4. Base it on Groovy 6.
> 5. Turn invokedynamic on.
> 1. Turning invokedynamic off is not a viable default. In Groovy
> 6.0.0 the classic call-site implementation has moved out of groovy-core
> into the separate groovy-callsite module, and that surface is on a path
> to deprecation. Core dispatch already uses invokedynamic.
> 6. Target 9.0.0 for the end of November 2026.
> 7. This release catches Grails up to Groovy. Apache Groovy 7 work
> has already started: https://github.com/apache/groovy
>
> 2. Grails 10 (the line previously discussed as 9.1.x)
> 1. Rename the planned 9.1.x line to 10.
> 2. Base it on Groovy 6 and Spring Boot 4.2.
> 3. Target 2027 Q1. Aim to release within one month of Spring Boot
> 4.2. That window is tight because of existing time commitments.
> 4. Use the major version bump so the release can carry material
> breaking changes and move the framework forward.
>
>
> James
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Daugherty <jd...@apache.org>.
I am fine skipping 4.2 for 8; my concern is not having times to add
features outside of waiting for a major release.
On Sun, Oct 11, 2026 at 3:49 PM James Fredley <ja...@apache.org>
wrote:
> I am OK with Grails 8.1.x based on Spring Boot 4.1. No concern there.
> Just wanted to avoid supporting Spring Boot 4.2 on Groovy 6 and also Groovy
> 5.
>
> James
>
> On 2026/10/11 11:06:08 James Daugherty via dev wrote:
> > Mattias has objected to https://github.com/apache/grails-core/pull/16554
> .
> > I oppose this proposal because I think it's important to release
> > enhancements in 8.0, especially those slated for 8.1 that are finished. I
> > do not want to wait for 9.0 as there's a strong chance it will be delayed
> > further.
> >
> > On Sun, Oct 11, 2026 at 10:42 AM James Daugherty <
> jdaugherty@jdresources.net>
> > wrote:
> >
> > > I'm ok with this proposal with one exception: if we can get the
> progress
> > > feature back ported to 8.0. This is that PR:
> > > https://github.com/apache/grails-core/pull/16554 I believe I'm still
> > > waiting on Mattias's feedback for this.
> > >
> > > -James
> > >
> > > On Sun, Oct 11, 2026 at 2:02 AM James Fredley <jamesfredley@apache.org
> >
> > > wrote:
> > >
> > >> Updates based on feedback.
> > >>
> > >> PROPOSAL
> > >>
> > >> 1. Grails 9.0.x
> > >> 1. Merge the 8.1.x branch into the 9.0.x branch.
> > >> 2. Do not release 8.1.x. Skip that line.
> > >> 3. Ship 9.0.x as a focused release that brings Grails current with
> > >> Groovy 6 without waiting for the next Spring Boot line.
> > >> 4. Base it on Groovy 6.
> > >> 5. Turn invokedynamic on by default.
> > >> Turning invokedynamic off is not a viable default. In Groovy
> 6.0.0
> > >> the classic call-site implementation has moved out of groovy-core
> into the
> > >> separate groovy-callsite module and is on a path to deprecation. Core
> > >> dispatch already uses invokedynamic.
> > >> 6. Include the two PRs from Scott related to JSON changes on Spring
> > >> Boot 4.1. Possible other minor and quick PRs.
> > >> 7. Target 9.0.0 for the end of November 2026.
> > >> 8. This release catches Grails up to Groovy. Apache Groovy 7 work
> has
> > >> already started: https://github.com/apache/groovy
> > >>
> > >> 2. Grails 9.1.x (previously discussed as the 10 / 9.1 line)
> > >> 1. Base it on Groovy 6 and Spring Boot 4.2.
> > >> 2. Target 2027 Q1. Aim to release within one month of Spring Boot
> 4.2
> > >> GA.
> > >> 3. Use this minor line for the Spring Boot 4.2 upgrade so the major
> > >> version bump is reserved for material breaking changes later.
> > >> 4. Set a firm target date to limit feature creep.
> > >>
> > >>
> > >> James
> > >>
> > >> On 2026/10/09 05:53:48 Søren Berg Glasius wrote:
> > >> > I tend to agree with Mattias.
> > >> >
> > >> > 9.0.x: Groovy 6, Spring 4.1 Major bump in Groovy version -> Major
> bump
> > >> in
> > >> > Grails version
> > >> > 9.1.x: Groovy 6, Spring 4.2 Minor bump in Spring version -> Minor
> bump
> > >> in
> > >> > Grails version
> > >> > 10.0.x: Groovy 6 (or 7), Spring 5, Major bump in Grails version
> > >> >
> > >> > And then set some target dates for those releases, so we don't end
> up
> > >> with
> > >> > feature creeping in the last weeks before that date.
> > >> >
> > >> > Getting 8.0.0 out of the door has been a feat and it's going to be
> GR8,
> > >> but
> > >> > it has also taken longer than it ought to.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Den tors. 8. okt. 2026 kl. 20.28 skrev Mattias Reichel <
> > >> matrei@apache.org>:
> > >> >
> > >> > > Then, the common ground would be 9.0 and 9.1?
> > >> > >
> > >> > > Den tors 8 okt. 2026 20:05James Fredley <ja...@apache.org>
> > >> skrev:
> > >> > >
> > >> > > > Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026,
> > >> which is
> > >> > > 6
> > >> > > > months after 4.1.0. https://endoflife.date/spring-boot
> > >> > > > Since that is Christmas, Jan is more likely.
> > >> > > >
> > >> > > > My #1 item on this discussion is getting Grails 9.0.0 on Groovy
> 6
> > >> out
> > >> > > soon
> > >> > > > and not waiting until Feb or March, so we can catch up to
> Groovy.
> > >> > > >
> > >> > > > My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy
> 6
> > >> and
> > >> > > > Groovy 5.
> > >> > > >
> > >> > > > The Grails 10.0.x vs 9.1.x version number is less important for
> me
> > >> > > >
> > >> > > > James
> > >> > > >
> > >> > > > On 2026/10/08 17:41:45 Mattias Reichel wrote:
> > >> > > > > Hi James, it seems we are not understanding each other.
> > >> > > > >
> > >> > > > > I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
> > >> > > > > I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and
> > >> Spring
> > >> > > > > Boot 4.2 right away.
> > >> > > > > There we will be current and up-to-date and able to test
> > >> everything.
> > >> > > > >
> > >> > > > > Why would it be January before we can adopt Spring Boot 4.2
> when
> > >> we
> > >> > > > > can start testing it on M2 today and RC1 in a couple of weeks.
> > >> > > > >
> > >> > > > > /Mattias
> > >> > > > >
> > >> > > > >
> > >> > > > > Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <
> > >> > > > jdaugherty@apache.org>:
> > >> > > > > >
> > >> > > > > > Hi Mattias,
> > >> > > > > >
> > >> > > > > > Our release policy says we can't update on minor versions,
> if we
> > >> > > could
> > >> > > > we could technically make 8.1 have Groovy 6 support. The
> reason a
> > >> major
> > >> > > is
> > >> > > > being proposed is because we're trying to follow our release
> policy.
> > >> > > > > >
> > >> > > > > > It will also likely be January before we can adopt Spring
> 4.2.
> > >> If we
> > >> > > > wait to put groovy in, 4 months will have passed and major
> Groovy
> > >> > > > development will have started back up again. The reason to get
> on
> > >> Groovy
> > >> > > > faster is so that we can be doing development while they are. We
> > >> have
> > >> > > been
> > >> > > > 2 versions behind to date and I'm skeptical we'll catch up if we
> > >> wait to
> > >> > > > release support for Groovy 6. Based on what I've already found
> with
> > >> 5,
> > >> > > I'm
> > >> > > > worried further language decisions will be made prior to our
> > >> adoption and
> > >> > > > it will be too late to change them by the time we find them.
> > >> > > > > >
> > >> > > > > > From a support perspective, support ends on 4.1 in Summer
> 2027
> > >> and
> > >> > > for
> > >> > > > 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6
> > >> months of
> > >> > > > additional support, so I wouldn't consider 4.2 a minor.
> > >> > > > > >
> > >> > > > > > What's being proposed is to skip / jump ahead so we don't
> stay
> > >> > > behind.
> > >> > > > > >
> > >> > > > > > -James
> > >> > > > > >
> > >> > > > > > On 2026/10/08 08:15:41 Mattias Reichel wrote:
> > >> > > > > > > My feeling is that with this plan we are moving too fast
> with
> > >> > > little
> > >> > > > gain.
> > >> > > > > > > I fail to see the up-sides of doing this, but I'm probably
> > >> missing
> > >> > > > something.
> > >> > > > > > >
> > >> > > > > > > From a user perspective I think it would be strange that
> the
> > >> main
> > >> > > > > > > selling point of Grails 10, as it stands now, would be a
> > >> minor bump
> > >> > > > of
> > >> > > > > > > Spring Boot.
> > >> > > > > > >
> > >> > > > > > > We need to help the rest of the Grails ecosystem to catch
> up
> > >> as
> > >> > > well.
> > >> > > > > > > I'm also pretty certain there will be much maintenance
> work on
> > >> > > > Grails 8.
> > >> > > > > > >
> > >> > > > > > > I think we should release Grails 9.0.0-M1 with Groovy 6
> > >> (indy-on)
> > >> > > > with
> > >> > > > > > > Spring Boot 4.2-M2 and start testing end applications
> early
> > >> against
> > >> > > > > > > that.
> > >> > > > > > >
> > >> > > > > > > As was the case for Grails 8, I'm sure there are also many
> > >> great
> > >> > > > ideas
> > >> > > > > > > and features that need time to develop, polish, review and
> > >> test
> > >> > > > before
> > >> > > > > > > going into a major release.
> > >> > > > > > >
> > >> > > > > > > Spring Boot RC1 is scheduled for October 22 which
> > >> historically has
> > >> > > > > > > meant a GA one month later. That schedule has been in flux
> > >> but it
> > >> > > > > > > seems the Spring team is trying to get back on track:
> > >> > > > > > >
> > >> > > >
> > >> > >
> > >>
> https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> > >> > > > > > >
> > >> > > > > > > Also important to factor in is the extra OSS support time
> of
> > >> Spring
> > >> > > > > > > Boot for Grails 9.
> > >> > > > > > >
> > >> > > > > > > If Spring Boot 4.2 is released late November, which my
> guess
> > >> it
> > >> > > will
> > >> > > > > > > be, we will have shot ourselves in the foot, doing a
> Grails 9
> > >> with
> > >> > > > > > > Boot 4.1.
> > >> > > > > > >
> > >> > > > > > > That Groovy master is already on Groovy 7 is to my
> > >> understanding
> > >> > > just
> > >> > > > > > > how that project works.
> > >> > > > > > > As soon as Groovy 6 was released, it became a maintenance
> > >> branch,
> > >> > > and
> > >> > > > > > > only gets backport fixes from master.
> > >> > > > > > >
> > >> > > > > > > /Mattias
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <
> > >> > > > jamesfredley@apache.org>:
> > >> > > > > > > >
> > >> > > > > > > > Hi all,
> > >> > > > > > > >
> > >> > > > > > > > This is a follow-up to the earlier thread and to today's
> > >> weekly
> > >> > > > meeting.
> > >> > > > > > > > This is a discuss thread, not a vote. The goal is to
> settle
> > >> the
> > >> > > > language
> > >> > > > > > > > for a follow-up [VOTE] on the next several Grails lines.
> > >> > > > > > > >
> > >> > > > > > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work
> toward
> > >> > > > Groovy 6 is
> > >> > > > > > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is
> out.
> > >> Groovy
> > >> > > > 7 work
> > >> > > > > > > > has already started: https://github.com/apache/groovy
> > >> > > > > > > >
> > >> > > > > > > > Please comment on the plan and on the wording. If you
> want
> > >> to
> > >> > > > change the
> > >> > > > > > > > language, copy the whole proposal block below, paste it
> > >> into your
> > >> > > > reply,
> > >> > > > > > > > and edit it there. Do not send a partial rewrite or a
> diff
> > >> of a
> > >> > > > > > > > sentence. A full replacement block is what we will carry
> > >> into the
> > >> > > > vote.
> > >> > > > > > > > If you agree with the block as written, a +1 on this
> thread
> > >> is
> > >> > > > enough.
> > >> > > > > > > > Discussion on this thread is not a binding vote.
> > >> > > > > > > >
> > >> > > > > > > > PROPOSAL (copy this whole block if you want to change
> the
> > >> > > language)
> > >> > > > > > > >
> > >> > > > > > > > 1. Grails 9.0.x
> > >> > > > > > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > >> > > > > > > > 2. Do not release 8.1.x. Skip that line.
> > >> > > > > > > > 3. Ship 9.0.x as a lighter release: bring Grails
> > >> current with
> > >> > > > > > > > Groovy, without waiting on the next Spring Boot line.
> > >> > > > > > > > 4. Base it on Groovy 6.
> > >> > > > > > > > 5. Turn invokedynamic on.
> > >> > > > > > > > 1. Turning invokedynamic off is not a viable
> > >> default. In
> > >> > > > Groovy
> > >> > > > > > > > 6.0.0 the classic call-site implementation has moved
> out of
> > >> > > > groovy-core
> > >> > > > > > > > into the separate groovy-callsite module, and that
> surface
> > >> is on
> > >> > > a
> > >> > > > path
> > >> > > > > > > > to deprecation. Core dispatch already uses
> invokedynamic.
> > >> > > > > > > > 6. Target 9.0.0 for the end of November 2026.
> > >> > > > > > > > 7. This release catches Grails up to Groovy. Apache
> > >> Groovy 7
> > >> > > > work
> > >> > > > > > > > has already started: https://github.com/apache/groovy
> > >> > > > > > > >
> > >> > > > > > > > 2. Grails 10 (the line previously discussed as 9.1.x)
> > >> > > > > > > > 1. Rename the planned 9.1.x line to 10.
> > >> > > > > > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > >> > > > > > > > 3. Target 2027 Q1. Aim to release within one month
> of
> > >> Spring
> > >> > > > Boot
> > >> > > > > > > > 4.2. That window is tight because of existing time
> > >> commitments.
> > >> > > > > > > > 4. Use the major version bump so the release can
> carry
> > >> > > material
> > >> > > > > > > > breaking changes and move the framework forward.
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > James
> > >> > > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Fredley <ja...@apache.org>.
I am OK with Grails 8.1.x based on Spring Boot 4.1. No concern there. Just wanted to avoid supporting Spring Boot 4.2 on Groovy 6 and also Groovy 5.
James
On 2026/10/11 11:06:08 James Daugherty via dev wrote:
> Mattias has objected to https://github.com/apache/grails-core/pull/16554 .
> I oppose this proposal because I think it's important to release
> enhancements in 8.0, especially those slated for 8.1 that are finished. I
> do not want to wait for 9.0 as there's a strong chance it will be delayed
> further.
>
> On Sun, Oct 11, 2026 at 10:42 AM James Daugherty <jd...@jdresources.net>
> wrote:
>
> > I'm ok with this proposal with one exception: if we can get the progress
> > feature back ported to 8.0. This is that PR:
> > https://github.com/apache/grails-core/pull/16554 I believe I'm still
> > waiting on Mattias's feedback for this.
> >
> > -James
> >
> > On Sun, Oct 11, 2026 at 2:02 AM James Fredley <ja...@apache.org>
> > wrote:
> >
> >> Updates based on feedback.
> >>
> >> PROPOSAL
> >>
> >> 1. Grails 9.0.x
> >> 1. Merge the 8.1.x branch into the 9.0.x branch.
> >> 2. Do not release 8.1.x. Skip that line.
> >> 3. Ship 9.0.x as a focused release that brings Grails current with
> >> Groovy 6 without waiting for the next Spring Boot line.
> >> 4. Base it on Groovy 6.
> >> 5. Turn invokedynamic on by default.
> >> Turning invokedynamic off is not a viable default. In Groovy 6.0.0
> >> the classic call-site implementation has moved out of groovy-core into the
> >> separate groovy-callsite module and is on a path to deprecation. Core
> >> dispatch already uses invokedynamic.
> >> 6. Include the two PRs from Scott related to JSON changes on Spring
> >> Boot 4.1. Possible other minor and quick PRs.
> >> 7. Target 9.0.0 for the end of November 2026.
> >> 8. This release catches Grails up to Groovy. Apache Groovy 7 work has
> >> already started: https://github.com/apache/groovy
> >>
> >> 2. Grails 9.1.x (previously discussed as the 10 / 9.1 line)
> >> 1. Base it on Groovy 6 and Spring Boot 4.2.
> >> 2. Target 2027 Q1. Aim to release within one month of Spring Boot 4.2
> >> GA.
> >> 3. Use this minor line for the Spring Boot 4.2 upgrade so the major
> >> version bump is reserved for material breaking changes later.
> >> 4. Set a firm target date to limit feature creep.
> >>
> >>
> >> James
> >>
> >> On 2026/10/09 05:53:48 Søren Berg Glasius wrote:
> >> > I tend to agree with Mattias.
> >> >
> >> > 9.0.x: Groovy 6, Spring 4.1 Major bump in Groovy version -> Major bump
> >> in
> >> > Grails version
> >> > 9.1.x: Groovy 6, Spring 4.2 Minor bump in Spring version -> Minor bump
> >> in
> >> > Grails version
> >> > 10.0.x: Groovy 6 (or 7), Spring 5, Major bump in Grails version
> >> >
> >> > And then set some target dates for those releases, so we don't end up
> >> with
> >> > feature creeping in the last weeks before that date.
> >> >
> >> > Getting 8.0.0 out of the door has been a feat and it's going to be GR8,
> >> but
> >> > it has also taken longer than it ought to.
> >> >
> >> >
> >> >
> >> >
> >> > Den tors. 8. okt. 2026 kl. 20.28 skrev Mattias Reichel <
> >> matrei@apache.org>:
> >> >
> >> > > Then, the common ground would be 9.0 and 9.1?
> >> > >
> >> > > Den tors 8 okt. 2026 20:05James Fredley <ja...@apache.org>
> >> skrev:
> >> > >
> >> > > > Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026,
> >> which is
> >> > > 6
> >> > > > months after 4.1.0. https://endoflife.date/spring-boot
> >> > > > Since that is Christmas, Jan is more likely.
> >> > > >
> >> > > > My #1 item on this discussion is getting Grails 9.0.0 on Groovy 6
> >> out
> >> > > soon
> >> > > > and not waiting until Feb or March, so we can catch up to Groovy.
> >> > > >
> >> > > > My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy 6
> >> and
> >> > > > Groovy 5.
> >> > > >
> >> > > > The Grails 10.0.x vs 9.1.x version number is less important for me
> >> > > >
> >> > > > James
> >> > > >
> >> > > > On 2026/10/08 17:41:45 Mattias Reichel wrote:
> >> > > > > Hi James, it seems we are not understanding each other.
> >> > > > >
> >> > > > > I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
> >> > > > > I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and
> >> Spring
> >> > > > > Boot 4.2 right away.
> >> > > > > There we will be current and up-to-date and able to test
> >> everything.
> >> > > > >
> >> > > > > Why would it be January before we can adopt Spring Boot 4.2 when
> >> we
> >> > > > > can start testing it on M2 today and RC1 in a couple of weeks.
> >> > > > >
> >> > > > > /Mattias
> >> > > > >
> >> > > > >
> >> > > > > Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <
> >> > > > jdaugherty@apache.org>:
> >> > > > > >
> >> > > > > > Hi Mattias,
> >> > > > > >
> >> > > > > > Our release policy says we can't update on minor versions, if we
> >> > > could
> >> > > > we could technically make 8.1 have Groovy 6 support. The reason a
> >> major
> >> > > is
> >> > > > being proposed is because we're trying to follow our release policy.
> >> > > > > >
> >> > > > > > It will also likely be January before we can adopt Spring 4.2.
> >> If we
> >> > > > wait to put groovy in, 4 months will have passed and major Groovy
> >> > > > development will have started back up again. The reason to get on
> >> Groovy
> >> > > > faster is so that we can be doing development while they are. We
> >> have
> >> > > been
> >> > > > 2 versions behind to date and I'm skeptical we'll catch up if we
> >> wait to
> >> > > > release support for Groovy 6. Based on what I've already found with
> >> 5,
> >> > > I'm
> >> > > > worried further language decisions will be made prior to our
> >> adoption and
> >> > > > it will be too late to change them by the time we find them.
> >> > > > > >
> >> > > > > > From a support perspective, support ends on 4.1 in Summer 2027
> >> and
> >> > > for
> >> > > > 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6
> >> months of
> >> > > > additional support, so I wouldn't consider 4.2 a minor.
> >> > > > > >
> >> > > > > > What's being proposed is to skip / jump ahead so we don't stay
> >> > > behind.
> >> > > > > >
> >> > > > > > -James
> >> > > > > >
> >> > > > > > On 2026/10/08 08:15:41 Mattias Reichel wrote:
> >> > > > > > > My feeling is that with this plan we are moving too fast with
> >> > > little
> >> > > > gain.
> >> > > > > > > I fail to see the up-sides of doing this, but I'm probably
> >> missing
> >> > > > something.
> >> > > > > > >
> >> > > > > > > From a user perspective I think it would be strange that the
> >> main
> >> > > > > > > selling point of Grails 10, as it stands now, would be a
> >> minor bump
> >> > > > of
> >> > > > > > > Spring Boot.
> >> > > > > > >
> >> > > > > > > We need to help the rest of the Grails ecosystem to catch up
> >> as
> >> > > well.
> >> > > > > > > I'm also pretty certain there will be much maintenance work on
> >> > > > Grails 8.
> >> > > > > > >
> >> > > > > > > I think we should release Grails 9.0.0-M1 with Groovy 6
> >> (indy-on)
> >> > > > with
> >> > > > > > > Spring Boot 4.2-M2 and start testing end applications early
> >> against
> >> > > > > > > that.
> >> > > > > > >
> >> > > > > > > As was the case for Grails 8, I'm sure there are also many
> >> great
> >> > > > ideas
> >> > > > > > > and features that need time to develop, polish, review and
> >> test
> >> > > > before
> >> > > > > > > going into a major release.
> >> > > > > > >
> >> > > > > > > Spring Boot RC1 is scheduled for October 22 which
> >> historically has
> >> > > > > > > meant a GA one month later. That schedule has been in flux
> >> but it
> >> > > > > > > seems the Spring team is trying to get back on track:
> >> > > > > > >
> >> > > >
> >> > >
> >> https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> >> > > > > > >
> >> > > > > > > Also important to factor in is the extra OSS support time of
> >> Spring
> >> > > > > > > Boot for Grails 9.
> >> > > > > > >
> >> > > > > > > If Spring Boot 4.2 is released late November, which my guess
> >> it
> >> > > will
> >> > > > > > > be, we will have shot ourselves in the foot, doing a Grails 9
> >> with
> >> > > > > > > Boot 4.1.
> >> > > > > > >
> >> > > > > > > That Groovy master is already on Groovy 7 is to my
> >> understanding
> >> > > just
> >> > > > > > > how that project works.
> >> > > > > > > As soon as Groovy 6 was released, it became a maintenance
> >> branch,
> >> > > and
> >> > > > > > > only gets backport fixes from master.
> >> > > > > > >
> >> > > > > > > /Mattias
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <
> >> > > > jamesfredley@apache.org>:
> >> > > > > > > >
> >> > > > > > > > Hi all,
> >> > > > > > > >
> >> > > > > > > > This is a follow-up to the earlier thread and to today's
> >> weekly
> >> > > > meeting.
> >> > > > > > > > This is a discuss thread, not a vote. The goal is to settle
> >> the
> >> > > > language
> >> > > > > > > > for a follow-up [VOTE] on the next several Grails lines.
> >> > > > > > > >
> >> > > > > > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward
> >> > > > Groovy 6 is
> >> > > > > > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out.
> >> Groovy
> >> > > > 7 work
> >> > > > > > > > has already started: https://github.com/apache/groovy
> >> > > > > > > >
> >> > > > > > > > Please comment on the plan and on the wording. If you want
> >> to
> >> > > > change the
> >> > > > > > > > language, copy the whole proposal block below, paste it
> >> into your
> >> > > > reply,
> >> > > > > > > > and edit it there. Do not send a partial rewrite or a diff
> >> of a
> >> > > > > > > > sentence. A full replacement block is what we will carry
> >> into the
> >> > > > vote.
> >> > > > > > > > If you agree with the block as written, a +1 on this thread
> >> is
> >> > > > enough.
> >> > > > > > > > Discussion on this thread is not a binding vote.
> >> > > > > > > >
> >> > > > > > > > PROPOSAL (copy this whole block if you want to change the
> >> > > language)
> >> > > > > > > >
> >> > > > > > > > 1. Grails 9.0.x
> >> > > > > > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> >> > > > > > > > 2. Do not release 8.1.x. Skip that line.
> >> > > > > > > > 3. Ship 9.0.x as a lighter release: bring Grails
> >> current with
> >> > > > > > > > Groovy, without waiting on the next Spring Boot line.
> >> > > > > > > > 4. Base it on Groovy 6.
> >> > > > > > > > 5. Turn invokedynamic on.
> >> > > > > > > > 1. Turning invokedynamic off is not a viable
> >> default. In
> >> > > > Groovy
> >> > > > > > > > 6.0.0 the classic call-site implementation has moved out of
> >> > > > groovy-core
> >> > > > > > > > into the separate groovy-callsite module, and that surface
> >> is on
> >> > > a
> >> > > > path
> >> > > > > > > > to deprecation. Core dispatch already uses invokedynamic.
> >> > > > > > > > 6. Target 9.0.0 for the end of November 2026.
> >> > > > > > > > 7. This release catches Grails up to Groovy. Apache
> >> Groovy 7
> >> > > > work
> >> > > > > > > > has already started: https://github.com/apache/groovy
> >> > > > > > > >
> >> > > > > > > > 2. Grails 10 (the line previously discussed as 9.1.x)
> >> > > > > > > > 1. Rename the planned 9.1.x line to 10.
> >> > > > > > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> >> > > > > > > > 3. Target 2027 Q1. Aim to release within one month of
> >> Spring
> >> > > > Boot
> >> > > > > > > > 4.2. That window is tight because of existing time
> >> commitments.
> >> > > > > > > > 4. Use the major version bump so the release can carry
> >> > > material
> >> > > > > > > > breaking changes and move the framework forward.
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > James
> >> > > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Daugherty via dev <de...@grails.apache.org>.
Mattias has objected to https://github.com/apache/grails-core/pull/16554 .
I oppose this proposal because I think it's important to release
enhancements in 8.0, especially those slated for 8.1 that are finished. I
do not want to wait for 9.0 as there's a strong chance it will be delayed
further.
On Sun, Oct 11, 2026 at 10:42 AM James Daugherty <jd...@jdresources.net>
wrote:
> I'm ok with this proposal with one exception: if we can get the progress
> feature back ported to 8.0. This is that PR:
> https://github.com/apache/grails-core/pull/16554 I believe I'm still
> waiting on Mattias's feedback for this.
>
> -James
>
> On Sun, Oct 11, 2026 at 2:02 AM James Fredley <ja...@apache.org>
> wrote:
>
>> Updates based on feedback.
>>
>> PROPOSAL
>>
>> 1. Grails 9.0.x
>> 1. Merge the 8.1.x branch into the 9.0.x branch.
>> 2. Do not release 8.1.x. Skip that line.
>> 3. Ship 9.0.x as a focused release that brings Grails current with
>> Groovy 6 without waiting for the next Spring Boot line.
>> 4. Base it on Groovy 6.
>> 5. Turn invokedynamic on by default.
>> Turning invokedynamic off is not a viable default. In Groovy 6.0.0
>> the classic call-site implementation has moved out of groovy-core into the
>> separate groovy-callsite module and is on a path to deprecation. Core
>> dispatch already uses invokedynamic.
>> 6. Include the two PRs from Scott related to JSON changes on Spring
>> Boot 4.1. Possible other minor and quick PRs.
>> 7. Target 9.0.0 for the end of November 2026.
>> 8. This release catches Grails up to Groovy. Apache Groovy 7 work has
>> already started: https://github.com/apache/groovy
>>
>> 2. Grails 9.1.x (previously discussed as the 10 / 9.1 line)
>> 1. Base it on Groovy 6 and Spring Boot 4.2.
>> 2. Target 2027 Q1. Aim to release within one month of Spring Boot 4.2
>> GA.
>> 3. Use this minor line for the Spring Boot 4.2 upgrade so the major
>> version bump is reserved for material breaking changes later.
>> 4. Set a firm target date to limit feature creep.
>>
>>
>> James
>>
>> On 2026/10/09 05:53:48 Søren Berg Glasius wrote:
>> > I tend to agree with Mattias.
>> >
>> > 9.0.x: Groovy 6, Spring 4.1 Major bump in Groovy version -> Major bump
>> in
>> > Grails version
>> > 9.1.x: Groovy 6, Spring 4.2 Minor bump in Spring version -> Minor bump
>> in
>> > Grails version
>> > 10.0.x: Groovy 6 (or 7), Spring 5, Major bump in Grails version
>> >
>> > And then set some target dates for those releases, so we don't end up
>> with
>> > feature creeping in the last weeks before that date.
>> >
>> > Getting 8.0.0 out of the door has been a feat and it's going to be GR8,
>> but
>> > it has also taken longer than it ought to.
>> >
>> >
>> >
>> >
>> > Den tors. 8. okt. 2026 kl. 20.28 skrev Mattias Reichel <
>> matrei@apache.org>:
>> >
>> > > Then, the common ground would be 9.0 and 9.1?
>> > >
>> > > Den tors 8 okt. 2026 20:05James Fredley <ja...@apache.org>
>> skrev:
>> > >
>> > > > Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026,
>> which is
>> > > 6
>> > > > months after 4.1.0. https://endoflife.date/spring-boot
>> > > > Since that is Christmas, Jan is more likely.
>> > > >
>> > > > My #1 item on this discussion is getting Grails 9.0.0 on Groovy 6
>> out
>> > > soon
>> > > > and not waiting until Feb or March, so we can catch up to Groovy.
>> > > >
>> > > > My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy 6
>> and
>> > > > Groovy 5.
>> > > >
>> > > > The Grails 10.0.x vs 9.1.x version number is less important for me
>> > > >
>> > > > James
>> > > >
>> > > > On 2026/10/08 17:41:45 Mattias Reichel wrote:
>> > > > > Hi James, it seems we are not understanding each other.
>> > > > >
>> > > > > I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
>> > > > > I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and
>> Spring
>> > > > > Boot 4.2 right away.
>> > > > > There we will be current and up-to-date and able to test
>> everything.
>> > > > >
>> > > > > Why would it be January before we can adopt Spring Boot 4.2 when
>> we
>> > > > > can start testing it on M2 today and RC1 in a couple of weeks.
>> > > > >
>> > > > > /Mattias
>> > > > >
>> > > > >
>> > > > > Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <
>> > > > jdaugherty@apache.org>:
>> > > > > >
>> > > > > > Hi Mattias,
>> > > > > >
>> > > > > > Our release policy says we can't update on minor versions, if we
>> > > could
>> > > > we could technically make 8.1 have Groovy 6 support. The reason a
>> major
>> > > is
>> > > > being proposed is because we're trying to follow our release policy.
>> > > > > >
>> > > > > > It will also likely be January before we can adopt Spring 4.2.
>> If we
>> > > > wait to put groovy in, 4 months will have passed and major Groovy
>> > > > development will have started back up again. The reason to get on
>> Groovy
>> > > > faster is so that we can be doing development while they are. We
>> have
>> > > been
>> > > > 2 versions behind to date and I'm skeptical we'll catch up if we
>> wait to
>> > > > release support for Groovy 6. Based on what I've already found with
>> 5,
>> > > I'm
>> > > > worried further language decisions will be made prior to our
>> adoption and
>> > > > it will be too late to change them by the time we find them.
>> > > > > >
>> > > > > > From a support perspective, support ends on 4.1 in Summer 2027
>> and
>> > > for
>> > > > 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6
>> months of
>> > > > additional support, so I wouldn't consider 4.2 a minor.
>> > > > > >
>> > > > > > What's being proposed is to skip / jump ahead so we don't stay
>> > > behind.
>> > > > > >
>> > > > > > -James
>> > > > > >
>> > > > > > On 2026/10/08 08:15:41 Mattias Reichel wrote:
>> > > > > > > My feeling is that with this plan we are moving too fast with
>> > > little
>> > > > gain.
>> > > > > > > I fail to see the up-sides of doing this, but I'm probably
>> missing
>> > > > something.
>> > > > > > >
>> > > > > > > From a user perspective I think it would be strange that the
>> main
>> > > > > > > selling point of Grails 10, as it stands now, would be a
>> minor bump
>> > > > of
>> > > > > > > Spring Boot.
>> > > > > > >
>> > > > > > > We need to help the rest of the Grails ecosystem to catch up
>> as
>> > > well.
>> > > > > > > I'm also pretty certain there will be much maintenance work on
>> > > > Grails 8.
>> > > > > > >
>> > > > > > > I think we should release Grails 9.0.0-M1 with Groovy 6
>> (indy-on)
>> > > > with
>> > > > > > > Spring Boot 4.2-M2 and start testing end applications early
>> against
>> > > > > > > that.
>> > > > > > >
>> > > > > > > As was the case for Grails 8, I'm sure there are also many
>> great
>> > > > ideas
>> > > > > > > and features that need time to develop, polish, review and
>> test
>> > > > before
>> > > > > > > going into a major release.
>> > > > > > >
>> > > > > > > Spring Boot RC1 is scheduled for October 22 which
>> historically has
>> > > > > > > meant a GA one month later. That schedule has been in flux
>> but it
>> > > > > > > seems the Spring team is trying to get back on track:
>> > > > > > >
>> > > >
>> > >
>> https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
>> > > > > > >
>> > > > > > > Also important to factor in is the extra OSS support time of
>> Spring
>> > > > > > > Boot for Grails 9.
>> > > > > > >
>> > > > > > > If Spring Boot 4.2 is released late November, which my guess
>> it
>> > > will
>> > > > > > > be, we will have shot ourselves in the foot, doing a Grails 9
>> with
>> > > > > > > Boot 4.1.
>> > > > > > >
>> > > > > > > That Groovy master is already on Groovy 7 is to my
>> understanding
>> > > just
>> > > > > > > how that project works.
>> > > > > > > As soon as Groovy 6 was released, it became a maintenance
>> branch,
>> > > and
>> > > > > > > only gets backport fixes from master.
>> > > > > > >
>> > > > > > > /Mattias
>> > > > > > >
>> > > > > > >
>> > > > > > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <
>> > > > jamesfredley@apache.org>:
>> > > > > > > >
>> > > > > > > > Hi all,
>> > > > > > > >
>> > > > > > > > This is a follow-up to the earlier thread and to today's
>> weekly
>> > > > meeting.
>> > > > > > > > This is a discuss thread, not a vote. The goal is to settle
>> the
>> > > > language
>> > > > > > > > for a follow-up [VOTE] on the next several Grails lines.
>> > > > > > > >
>> > > > > > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward
>> > > > Groovy 6 is
>> > > > > > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out.
>> Groovy
>> > > > 7 work
>> > > > > > > > has already started: https://github.com/apache/groovy
>> > > > > > > >
>> > > > > > > > Please comment on the plan and on the wording. If you want
>> to
>> > > > change the
>> > > > > > > > language, copy the whole proposal block below, paste it
>> into your
>> > > > reply,
>> > > > > > > > and edit it there. Do not send a partial rewrite or a diff
>> of a
>> > > > > > > > sentence. A full replacement block is what we will carry
>> into the
>> > > > vote.
>> > > > > > > > If you agree with the block as written, a +1 on this thread
>> is
>> > > > enough.
>> > > > > > > > Discussion on this thread is not a binding vote.
>> > > > > > > >
>> > > > > > > > PROPOSAL (copy this whole block if you want to change the
>> > > language)
>> > > > > > > >
>> > > > > > > > 1. Grails 9.0.x
>> > > > > > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
>> > > > > > > > 2. Do not release 8.1.x. Skip that line.
>> > > > > > > > 3. Ship 9.0.x as a lighter release: bring Grails
>> current with
>> > > > > > > > Groovy, without waiting on the next Spring Boot line.
>> > > > > > > > 4. Base it on Groovy 6.
>> > > > > > > > 5. Turn invokedynamic on.
>> > > > > > > > 1. Turning invokedynamic off is not a viable
>> default. In
>> > > > Groovy
>> > > > > > > > 6.0.0 the classic call-site implementation has moved out of
>> > > > groovy-core
>> > > > > > > > into the separate groovy-callsite module, and that surface
>> is on
>> > > a
>> > > > path
>> > > > > > > > to deprecation. Core dispatch already uses invokedynamic.
>> > > > > > > > 6. Target 9.0.0 for the end of November 2026.
>> > > > > > > > 7. This release catches Grails up to Groovy. Apache
>> Groovy 7
>> > > > work
>> > > > > > > > has already started: https://github.com/apache/groovy
>> > > > > > > >
>> > > > > > > > 2. Grails 10 (the line previously discussed as 9.1.x)
>> > > > > > > > 1. Rename the planned 9.1.x line to 10.
>> > > > > > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
>> > > > > > > > 3. Target 2027 Q1. Aim to release within one month of
>> Spring
>> > > > Boot
>> > > > > > > > 4.2. That window is tight because of existing time
>> commitments.
>> > > > > > > > 4. Use the major version bump so the release can carry
>> > > material
>> > > > > > > > breaking changes and move the framework forward.
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > James
>> > > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Daugherty via dev <de...@grails.apache.org>.
I'm ok with this proposal with one exception: if we can get the progress
feature back ported to 8.0. This is that PR:
https://github.com/apache/grails-core/pull/16554 I believe I'm still
waiting on Mattias's feedback for this.
-James
On Sun, Oct 11, 2026 at 2:02 AM James Fredley <ja...@apache.org>
wrote:
> Updates based on feedback.
>
> PROPOSAL
>
> 1. Grails 9.0.x
> 1. Merge the 8.1.x branch into the 9.0.x branch.
> 2. Do not release 8.1.x. Skip that line.
> 3. Ship 9.0.x as a focused release that brings Grails current with
> Groovy 6 without waiting for the next Spring Boot line.
> 4. Base it on Groovy 6.
> 5. Turn invokedynamic on by default.
> Turning invokedynamic off is not a viable default. In Groovy 6.0.0
> the classic call-site implementation has moved out of groovy-core into the
> separate groovy-callsite module and is on a path to deprecation. Core
> dispatch already uses invokedynamic.
> 6. Include the two PRs from Scott related to JSON changes on Spring
> Boot 4.1. Possible other minor and quick PRs.
> 7. Target 9.0.0 for the end of November 2026.
> 8. This release catches Grails up to Groovy. Apache Groovy 7 work has
> already started: https://github.com/apache/groovy
>
> 2. Grails 9.1.x (previously discussed as the 10 / 9.1 line)
> 1. Base it on Groovy 6 and Spring Boot 4.2.
> 2. Target 2027 Q1. Aim to release within one month of Spring Boot 4.2
> GA.
> 3. Use this minor line for the Spring Boot 4.2 upgrade so the major
> version bump is reserved for material breaking changes later.
> 4. Set a firm target date to limit feature creep.
>
>
> James
>
> On 2026/10/09 05:53:48 Søren Berg Glasius wrote:
> > I tend to agree with Mattias.
> >
> > 9.0.x: Groovy 6, Spring 4.1 Major bump in Groovy version -> Major bump in
> > Grails version
> > 9.1.x: Groovy 6, Spring 4.2 Minor bump in Spring version -> Minor bump in
> > Grails version
> > 10.0.x: Groovy 6 (or 7), Spring 5, Major bump in Grails version
> >
> > And then set some target dates for those releases, so we don't end up
> with
> > feature creeping in the last weeks before that date.
> >
> > Getting 8.0.0 out of the door has been a feat and it's going to be GR8,
> but
> > it has also taken longer than it ought to.
> >
> >
> >
> >
> > Den tors. 8. okt. 2026 kl. 20.28 skrev Mattias Reichel <
> matrei@apache.org>:
> >
> > > Then, the common ground would be 9.0 and 9.1?
> > >
> > > Den tors 8 okt. 2026 20:05James Fredley <ja...@apache.org>
> skrev:
> > >
> > > > Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026,
> which is
> > > 6
> > > > months after 4.1.0. https://endoflife.date/spring-boot
> > > > Since that is Christmas, Jan is more likely.
> > > >
> > > > My #1 item on this discussion is getting Grails 9.0.0 on Groovy 6 out
> > > soon
> > > > and not waiting until Feb or March, so we can catch up to Groovy.
> > > >
> > > > My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy 6 and
> > > > Groovy 5.
> > > >
> > > > The Grails 10.0.x vs 9.1.x version number is less important for me
> > > >
> > > > James
> > > >
> > > > On 2026/10/08 17:41:45 Mattias Reichel wrote:
> > > > > Hi James, it seems we are not understanding each other.
> > > > >
> > > > > I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
> > > > > I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and Spring
> > > > > Boot 4.2 right away.
> > > > > There we will be current and up-to-date and able to test
> everything.
> > > > >
> > > > > Why would it be January before we can adopt Spring Boot 4.2 when we
> > > > > can start testing it on M2 today and RC1 in a couple of weeks.
> > > > >
> > > > > /Mattias
> > > > >
> > > > >
> > > > > Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <
> > > > jdaugherty@apache.org>:
> > > > > >
> > > > > > Hi Mattias,
> > > > > >
> > > > > > Our release policy says we can't update on minor versions, if we
> > > could
> > > > we could technically make 8.1 have Groovy 6 support. The reason a
> major
> > > is
> > > > being proposed is because we're trying to follow our release policy.
> > > > > >
> > > > > > It will also likely be January before we can adopt Spring 4.2.
> If we
> > > > wait to put groovy in, 4 months will have passed and major Groovy
> > > > development will have started back up again. The reason to get on
> Groovy
> > > > faster is so that we can be doing development while they are. We have
> > > been
> > > > 2 versions behind to date and I'm skeptical we'll catch up if we
> wait to
> > > > release support for Groovy 6. Based on what I've already found with
> 5,
> > > I'm
> > > > worried further language decisions will be made prior to our
> adoption and
> > > > it will be too late to change them by the time we find them.
> > > > > >
> > > > > > From a support perspective, support ends on 4.1 in Summer 2027
> and
> > > for
> > > > 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6
> months of
> > > > additional support, so I wouldn't consider 4.2 a minor.
> > > > > >
> > > > > > What's being proposed is to skip / jump ahead so we don't stay
> > > behind.
> > > > > >
> > > > > > -James
> > > > > >
> > > > > > On 2026/10/08 08:15:41 Mattias Reichel wrote:
> > > > > > > My feeling is that with this plan we are moving too fast with
> > > little
> > > > gain.
> > > > > > > I fail to see the up-sides of doing this, but I'm probably
> missing
> > > > something.
> > > > > > >
> > > > > > > From a user perspective I think it would be strange that the
> main
> > > > > > > selling point of Grails 10, as it stands now, would be a minor
> bump
> > > > of
> > > > > > > Spring Boot.
> > > > > > >
> > > > > > > We need to help the rest of the Grails ecosystem to catch up as
> > > well.
> > > > > > > I'm also pretty certain there will be much maintenance work on
> > > > Grails 8.
> > > > > > >
> > > > > > > I think we should release Grails 9.0.0-M1 with Groovy 6
> (indy-on)
> > > > with
> > > > > > > Spring Boot 4.2-M2 and start testing end applications early
> against
> > > > > > > that.
> > > > > > >
> > > > > > > As was the case for Grails 8, I'm sure there are also many
> great
> > > > ideas
> > > > > > > and features that need time to develop, polish, review and test
> > > > before
> > > > > > > going into a major release.
> > > > > > >
> > > > > > > Spring Boot RC1 is scheduled for October 22 which historically
> has
> > > > > > > meant a GA one month later. That schedule has been in flux but
> it
> > > > > > > seems the Spring team is trying to get back on track:
> > > > > > >
> > > >
> > >
> https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> > > > > > >
> > > > > > > Also important to factor in is the extra OSS support time of
> Spring
> > > > > > > Boot for Grails 9.
> > > > > > >
> > > > > > > If Spring Boot 4.2 is released late November, which my guess it
> > > will
> > > > > > > be, we will have shot ourselves in the foot, doing a Grails 9
> with
> > > > > > > Boot 4.1.
> > > > > > >
> > > > > > > That Groovy master is already on Groovy 7 is to my
> understanding
> > > just
> > > > > > > how that project works.
> > > > > > > As soon as Groovy 6 was released, it became a maintenance
> branch,
> > > and
> > > > > > > only gets backport fixes from master.
> > > > > > >
> > > > > > > /Mattias
> > > > > > >
> > > > > > >
> > > > > > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <
> > > > jamesfredley@apache.org>:
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > This is a follow-up to the earlier thread and to today's
> weekly
> > > > meeting.
> > > > > > > > This is a discuss thread, not a vote. The goal is to settle
> the
> > > > language
> > > > > > > > for a follow-up [VOTE] on the next several Grails lines.
> > > > > > > >
> > > > > > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward
> > > > Groovy 6 is
> > > > > > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out.
> Groovy
> > > > 7 work
> > > > > > > > has already started: https://github.com/apache/groovy
> > > > > > > >
> > > > > > > > Please comment on the plan and on the wording. If you want to
> > > > change the
> > > > > > > > language, copy the whole proposal block below, paste it into
> your
> > > > reply,
> > > > > > > > and edit it there. Do not send a partial rewrite or a diff
> of a
> > > > > > > > sentence. A full replacement block is what we will carry
> into the
> > > > vote.
> > > > > > > > If you agree with the block as written, a +1 on this thread
> is
> > > > enough.
> > > > > > > > Discussion on this thread is not a binding vote.
> > > > > > > >
> > > > > > > > PROPOSAL (copy this whole block if you want to change the
> > > language)
> > > > > > > >
> > > > > > > > 1. Grails 9.0.x
> > > > > > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > > > > > > > 2. Do not release 8.1.x. Skip that line.
> > > > > > > > 3. Ship 9.0.x as a lighter release: bring Grails current
> with
> > > > > > > > Groovy, without waiting on the next Spring Boot line.
> > > > > > > > 4. Base it on Groovy 6.
> > > > > > > > 5. Turn invokedynamic on.
> > > > > > > > 1. Turning invokedynamic off is not a viable default.
> In
> > > > Groovy
> > > > > > > > 6.0.0 the classic call-site implementation has moved out of
> > > > groovy-core
> > > > > > > > into the separate groovy-callsite module, and that surface
> is on
> > > a
> > > > path
> > > > > > > > to deprecation. Core dispatch already uses invokedynamic.
> > > > > > > > 6. Target 9.0.0 for the end of November 2026.
> > > > > > > > 7. This release catches Grails up to Groovy. Apache
> Groovy 7
> > > > work
> > > > > > > > has already started: https://github.com/apache/groovy
> > > > > > > >
> > > > > > > > 2. Grails 10 (the line previously discussed as 9.1.x)
> > > > > > > > 1. Rename the planned 9.1.x line to 10.
> > > > > > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > > > > > > > 3. Target 2027 Q1. Aim to release within one month of
> Spring
> > > > Boot
> > > > > > > > 4.2. That window is tight because of existing time
> commitments.
> > > > > > > > 4. Use the major version bump so the release can carry
> > > material
> > > > > > > > breaking changes and move the framework forward.
> > > > > > > >
> > > > > > > >
> > > > > > > > James
> > > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Fredley <ja...@apache.org>.
Updates based on feedback.
PROPOSAL
1. Grails 9.0.x
1. Merge the 8.1.x branch into the 9.0.x branch.
2. Do not release 8.1.x. Skip that line.
3. Ship 9.0.x as a focused release that brings Grails current with Groovy 6 without waiting for the next Spring Boot line.
4. Base it on Groovy 6.
5. Turn invokedynamic on by default.
Turning invokedynamic off is not a viable default. In Groovy 6.0.0 the classic call-site implementation has moved out of groovy-core into the separate groovy-callsite module and is on a path to deprecation. Core dispatch already uses invokedynamic.
6. Include the two PRs from Scott related to JSON changes on Spring Boot 4.1. Possible other minor and quick PRs.
7. Target 9.0.0 for the end of November 2026.
8. This release catches Grails up to Groovy. Apache Groovy 7 work has already started: https://github.com/apache/groovy
2. Grails 9.1.x (previously discussed as the 10 / 9.1 line)
1. Base it on Groovy 6 and Spring Boot 4.2.
2. Target 2027 Q1. Aim to release within one month of Spring Boot 4.2 GA.
3. Use this minor line for the Spring Boot 4.2 upgrade so the major version bump is reserved for material breaking changes later.
4. Set a firm target date to limit feature creep.
James
On 2026/10/09 05:53:48 Søren Berg Glasius wrote:
> I tend to agree with Mattias.
>
> 9.0.x: Groovy 6, Spring 4.1 Major bump in Groovy version -> Major bump in
> Grails version
> 9.1.x: Groovy 6, Spring 4.2 Minor bump in Spring version -> Minor bump in
> Grails version
> 10.0.x: Groovy 6 (or 7), Spring 5, Major bump in Grails version
>
> And then set some target dates for those releases, so we don't end up with
> feature creeping in the last weeks before that date.
>
> Getting 8.0.0 out of the door has been a feat and it's going to be GR8, but
> it has also taken longer than it ought to.
>
>
>
>
> Den tors. 8. okt. 2026 kl. 20.28 skrev Mattias Reichel <ma...@apache.org>:
>
> > Then, the common ground would be 9.0 and 9.1?
> >
> > Den tors 8 okt. 2026 20:05James Fredley <ja...@apache.org> skrev:
> >
> > > Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026, which is
> > 6
> > > months after 4.1.0. https://endoflife.date/spring-boot
> > > Since that is Christmas, Jan is more likely.
> > >
> > > My #1 item on this discussion is getting Grails 9.0.0 on Groovy 6 out
> > soon
> > > and not waiting until Feb or March, so we can catch up to Groovy.
> > >
> > > My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy 6 and
> > > Groovy 5.
> > >
> > > The Grails 10.0.x vs 9.1.x version number is less important for me
> > >
> > > James
> > >
> > > On 2026/10/08 17:41:45 Mattias Reichel wrote:
> > > > Hi James, it seems we are not understanding each other.
> > > >
> > > > I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
> > > > I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and Spring
> > > > Boot 4.2 right away.
> > > > There we will be current and up-to-date and able to test everything.
> > > >
> > > > Why would it be January before we can adopt Spring Boot 4.2 when we
> > > > can start testing it on M2 today and RC1 in a couple of weeks.
> > > >
> > > > /Mattias
> > > >
> > > >
> > > > Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <
> > > jdaugherty@apache.org>:
> > > > >
> > > > > Hi Mattias,
> > > > >
> > > > > Our release policy says we can't update on minor versions, if we
> > could
> > > we could technically make 8.1 have Groovy 6 support. The reason a major
> > is
> > > being proposed is because we're trying to follow our release policy.
> > > > >
> > > > > It will also likely be January before we can adopt Spring 4.2. If we
> > > wait to put groovy in, 4 months will have passed and major Groovy
> > > development will have started back up again. The reason to get on Groovy
> > > faster is so that we can be doing development while they are. We have
> > been
> > > 2 versions behind to date and I'm skeptical we'll catch up if we wait to
> > > release support for Groovy 6. Based on what I've already found with 5,
> > I'm
> > > worried further language decisions will be made prior to our adoption and
> > > it will be too late to change them by the time we find them.
> > > > >
> > > > > From a support perspective, support ends on 4.1 in Summer 2027 and
> > for
> > > 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6 months of
> > > additional support, so I wouldn't consider 4.2 a minor.
> > > > >
> > > > > What's being proposed is to skip / jump ahead so we don't stay
> > behind.
> > > > >
> > > > > -James
> > > > >
> > > > > On 2026/10/08 08:15:41 Mattias Reichel wrote:
> > > > > > My feeling is that with this plan we are moving too fast with
> > little
> > > gain.
> > > > > > I fail to see the up-sides of doing this, but I'm probably missing
> > > something.
> > > > > >
> > > > > > From a user perspective I think it would be strange that the main
> > > > > > selling point of Grails 10, as it stands now, would be a minor bump
> > > of
> > > > > > Spring Boot.
> > > > > >
> > > > > > We need to help the rest of the Grails ecosystem to catch up as
> > well.
> > > > > > I'm also pretty certain there will be much maintenance work on
> > > Grails 8.
> > > > > >
> > > > > > I think we should release Grails 9.0.0-M1 with Groovy 6 (indy-on)
> > > with
> > > > > > Spring Boot 4.2-M2 and start testing end applications early against
> > > > > > that.
> > > > > >
> > > > > > As was the case for Grails 8, I'm sure there are also many great
> > > ideas
> > > > > > and features that need time to develop, polish, review and test
> > > before
> > > > > > going into a major release.
> > > > > >
> > > > > > Spring Boot RC1 is scheduled for October 22 which historically has
> > > > > > meant a GA one month later. That schedule has been in flux but it
> > > > > > seems the Spring team is trying to get back on track:
> > > > > >
> > >
> > https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> > > > > >
> > > > > > Also important to factor in is the extra OSS support time of Spring
> > > > > > Boot for Grails 9.
> > > > > >
> > > > > > If Spring Boot 4.2 is released late November, which my guess it
> > will
> > > > > > be, we will have shot ourselves in the foot, doing a Grails 9 with
> > > > > > Boot 4.1.
> > > > > >
> > > > > > That Groovy master is already on Groovy 7 is to my understanding
> > just
> > > > > > how that project works.
> > > > > > As soon as Groovy 6 was released, it became a maintenance branch,
> > and
> > > > > > only gets backport fixes from master.
> > > > > >
> > > > > > /Mattias
> > > > > >
> > > > > >
> > > > > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <
> > > jamesfredley@apache.org>:
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > This is a follow-up to the earlier thread and to today's weekly
> > > meeting.
> > > > > > > This is a discuss thread, not a vote. The goal is to settle the
> > > language
> > > > > > > for a follow-up [VOTE] on the next several Grails lines.
> > > > > > >
> > > > > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward
> > > Groovy 6 is
> > > > > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy
> > > 7 work
> > > > > > > has already started: https://github.com/apache/groovy
> > > > > > >
> > > > > > > Please comment on the plan and on the wording. If you want to
> > > change the
> > > > > > > language, copy the whole proposal block below, paste it into your
> > > reply,
> > > > > > > and edit it there. Do not send a partial rewrite or a diff of a
> > > > > > > sentence. A full replacement block is what we will carry into the
> > > vote.
> > > > > > > If you agree with the block as written, a +1 on this thread is
> > > enough.
> > > > > > > Discussion on this thread is not a binding vote.
> > > > > > >
> > > > > > > PROPOSAL (copy this whole block if you want to change the
> > language)
> > > > > > >
> > > > > > > 1. Grails 9.0.x
> > > > > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > > > > > > 2. Do not release 8.1.x. Skip that line.
> > > > > > > 3. Ship 9.0.x as a lighter release: bring Grails current with
> > > > > > > Groovy, without waiting on the next Spring Boot line.
> > > > > > > 4. Base it on Groovy 6.
> > > > > > > 5. Turn invokedynamic on.
> > > > > > > 1. Turning invokedynamic off is not a viable default. In
> > > Groovy
> > > > > > > 6.0.0 the classic call-site implementation has moved out of
> > > groovy-core
> > > > > > > into the separate groovy-callsite module, and that surface is on
> > a
> > > path
> > > > > > > to deprecation. Core dispatch already uses invokedynamic.
> > > > > > > 6. Target 9.0.0 for the end of November 2026.
> > > > > > > 7. This release catches Grails up to Groovy. Apache Groovy 7
> > > work
> > > > > > > has already started: https://github.com/apache/groovy
> > > > > > >
> > > > > > > 2. Grails 10 (the line previously discussed as 9.1.x)
> > > > > > > 1. Rename the planned 9.1.x line to 10.
> > > > > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > > > > > > 3. Target 2027 Q1. Aim to release within one month of Spring
> > > Boot
> > > > > > > 4.2. That window is tight because of existing time commitments.
> > > > > > > 4. Use the major version bump so the release can carry
> > material
> > > > > > > breaking changes and move the framework forward.
> > > > > > >
> > > > > > >
> > > > > > > James
> > > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by Søren Berg Glasius <so...@glasius.dk>.
I tend to agree with Mattias.
9.0.x: Groovy 6, Spring 4.1 Major bump in Groovy version -> Major bump in
Grails version
9.1.x: Groovy 6, Spring 4.2 Minor bump in Spring version -> Minor bump in
Grails version
10.0.x: Groovy 6 (or 7), Spring 5, Major bump in Grails version
And then set some target dates for those releases, so we don't end up with
feature creeping in the last weeks before that date.
Getting 8.0.0 out of the door has been a feat and it's going to be GR8, but
it has also taken longer than it ought to.
Den tors. 8. okt. 2026 kl. 20.28 skrev Mattias Reichel <ma...@apache.org>:
> Then, the common ground would be 9.0 and 9.1?
>
> Den tors 8 okt. 2026 20:05James Fredley <ja...@apache.org> skrev:
>
> > Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026, which is
> 6
> > months after 4.1.0. https://endoflife.date/spring-boot
> > Since that is Christmas, Jan is more likely.
> >
> > My #1 item on this discussion is getting Grails 9.0.0 on Groovy 6 out
> soon
> > and not waiting until Feb or March, so we can catch up to Groovy.
> >
> > My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy 6 and
> > Groovy 5.
> >
> > The Grails 10.0.x vs 9.1.x version number is less important for me
> >
> > James
> >
> > On 2026/10/08 17:41:45 Mattias Reichel wrote:
> > > Hi James, it seems we are not understanding each other.
> > >
> > > I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
> > > I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and Spring
> > > Boot 4.2 right away.
> > > There we will be current and up-to-date and able to test everything.
> > >
> > > Why would it be January before we can adopt Spring Boot 4.2 when we
> > > can start testing it on M2 today and RC1 in a couple of weeks.
> > >
> > > /Mattias
> > >
> > >
> > > Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <
> > jdaugherty@apache.org>:
> > > >
> > > > Hi Mattias,
> > > >
> > > > Our release policy says we can't update on minor versions, if we
> could
> > we could technically make 8.1 have Groovy 6 support. The reason a major
> is
> > being proposed is because we're trying to follow our release policy.
> > > >
> > > > It will also likely be January before we can adopt Spring 4.2. If we
> > wait to put groovy in, 4 months will have passed and major Groovy
> > development will have started back up again. The reason to get on Groovy
> > faster is so that we can be doing development while they are. We have
> been
> > 2 versions behind to date and I'm skeptical we'll catch up if we wait to
> > release support for Groovy 6. Based on what I've already found with 5,
> I'm
> > worried further language decisions will be made prior to our adoption and
> > it will be too late to change them by the time we find them.
> > > >
> > > > From a support perspective, support ends on 4.1 in Summer 2027 and
> for
> > 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6 months of
> > additional support, so I wouldn't consider 4.2 a minor.
> > > >
> > > > What's being proposed is to skip / jump ahead so we don't stay
> behind.
> > > >
> > > > -James
> > > >
> > > > On 2026/10/08 08:15:41 Mattias Reichel wrote:
> > > > > My feeling is that with this plan we are moving too fast with
> little
> > gain.
> > > > > I fail to see the up-sides of doing this, but I'm probably missing
> > something.
> > > > >
> > > > > From a user perspective I think it would be strange that the main
> > > > > selling point of Grails 10, as it stands now, would be a minor bump
> > of
> > > > > Spring Boot.
> > > > >
> > > > > We need to help the rest of the Grails ecosystem to catch up as
> well.
> > > > > I'm also pretty certain there will be much maintenance work on
> > Grails 8.
> > > > >
> > > > > I think we should release Grails 9.0.0-M1 with Groovy 6 (indy-on)
> > with
> > > > > Spring Boot 4.2-M2 and start testing end applications early against
> > > > > that.
> > > > >
> > > > > As was the case for Grails 8, I'm sure there are also many great
> > ideas
> > > > > and features that need time to develop, polish, review and test
> > before
> > > > > going into a major release.
> > > > >
> > > > > Spring Boot RC1 is scheduled for October 22 which historically has
> > > > > meant a GA one month later. That schedule has been in flux but it
> > > > > seems the Spring team is trying to get back on track:
> > > > >
> >
> https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> > > > >
> > > > > Also important to factor in is the extra OSS support time of Spring
> > > > > Boot for Grails 9.
> > > > >
> > > > > If Spring Boot 4.2 is released late November, which my guess it
> will
> > > > > be, we will have shot ourselves in the foot, doing a Grails 9 with
> > > > > Boot 4.1.
> > > > >
> > > > > That Groovy master is already on Groovy 7 is to my understanding
> just
> > > > > how that project works.
> > > > > As soon as Groovy 6 was released, it became a maintenance branch,
> and
> > > > > only gets backport fixes from master.
> > > > >
> > > > > /Mattias
> > > > >
> > > > >
> > > > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <
> > jamesfredley@apache.org>:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > This is a follow-up to the earlier thread and to today's weekly
> > meeting.
> > > > > > This is a discuss thread, not a vote. The goal is to settle the
> > language
> > > > > > for a follow-up [VOTE] on the next several Grails lines.
> > > > > >
> > > > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward
> > Groovy 6 is
> > > > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy
> > 7 work
> > > > > > has already started: https://github.com/apache/groovy
> > > > > >
> > > > > > Please comment on the plan and on the wording. If you want to
> > change the
> > > > > > language, copy the whole proposal block below, paste it into your
> > reply,
> > > > > > and edit it there. Do not send a partial rewrite or a diff of a
> > > > > > sentence. A full replacement block is what we will carry into the
> > vote.
> > > > > > If you agree with the block as written, a +1 on this thread is
> > enough.
> > > > > > Discussion on this thread is not a binding vote.
> > > > > >
> > > > > > PROPOSAL (copy this whole block if you want to change the
> language)
> > > > > >
> > > > > > 1. Grails 9.0.x
> > > > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > > > > > 2. Do not release 8.1.x. Skip that line.
> > > > > > 3. Ship 9.0.x as a lighter release: bring Grails current with
> > > > > > Groovy, without waiting on the next Spring Boot line.
> > > > > > 4. Base it on Groovy 6.
> > > > > > 5. Turn invokedynamic on.
> > > > > > 1. Turning invokedynamic off is not a viable default. In
> > Groovy
> > > > > > 6.0.0 the classic call-site implementation has moved out of
> > groovy-core
> > > > > > into the separate groovy-callsite module, and that surface is on
> a
> > path
> > > > > > to deprecation. Core dispatch already uses invokedynamic.
> > > > > > 6. Target 9.0.0 for the end of November 2026.
> > > > > > 7. This release catches Grails up to Groovy. Apache Groovy 7
> > work
> > > > > > has already started: https://github.com/apache/groovy
> > > > > >
> > > > > > 2. Grails 10 (the line previously discussed as 9.1.x)
> > > > > > 1. Rename the planned 9.1.x line to 10.
> > > > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > > > > > 3. Target 2027 Q1. Aim to release within one month of Spring
> > Boot
> > > > > > 4.2. That window is tight because of existing time commitments.
> > > > > > 4. Use the major version bump so the release can carry
> material
> > > > > > breaking changes and move the framework forward.
> > > > > >
> > > > > >
> > > > > > James
> > > > >
> > >
> >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by Mattias Reichel <ma...@apache.org>.
Then, the common ground would be 9.0 and 9.1?
Den tors 8 okt. 2026 20:05James Fredley <ja...@apache.org> skrev:
> Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026, which is 6
> months after 4.1.0. https://endoflife.date/spring-boot
> Since that is Christmas, Jan is more likely.
>
> My #1 item on this discussion is getting Grails 9.0.0 on Groovy 6 out soon
> and not waiting until Feb or March, so we can catch up to Groovy.
>
> My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy 6 and
> Groovy 5.
>
> The Grails 10.0.x vs 9.1.x version number is less important for me
>
> James
>
> On 2026/10/08 17:41:45 Mattias Reichel wrote:
> > Hi James, it seems we are not understanding each other.
> >
> > I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
> > I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and Spring
> > Boot 4.2 right away.
> > There we will be current and up-to-date and able to test everything.
> >
> > Why would it be January before we can adopt Spring Boot 4.2 when we
> > can start testing it on M2 today and RC1 in a couple of weeks.
> >
> > /Mattias
> >
> >
> > Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <
> jdaugherty@apache.org>:
> > >
> > > Hi Mattias,
> > >
> > > Our release policy says we can't update on minor versions, if we could
> we could technically make 8.1 have Groovy 6 support. The reason a major is
> being proposed is because we're trying to follow our release policy.
> > >
> > > It will also likely be January before we can adopt Spring 4.2. If we
> wait to put groovy in, 4 months will have passed and major Groovy
> development will have started back up again. The reason to get on Groovy
> faster is so that we can be doing development while they are. We have been
> 2 versions behind to date and I'm skeptical we'll catch up if we wait to
> release support for Groovy 6. Based on what I've already found with 5, I'm
> worried further language decisions will be made prior to our adoption and
> it will be too late to change them by the time we find them.
> > >
> > > From a support perspective, support ends on 4.1 in Summer 2027 and for
> 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6 months of
> additional support, so I wouldn't consider 4.2 a minor.
> > >
> > > What's being proposed is to skip / jump ahead so we don't stay behind.
> > >
> > > -James
> > >
> > > On 2026/10/08 08:15:41 Mattias Reichel wrote:
> > > > My feeling is that with this plan we are moving too fast with little
> gain.
> > > > I fail to see the up-sides of doing this, but I'm probably missing
> something.
> > > >
> > > > From a user perspective I think it would be strange that the main
> > > > selling point of Grails 10, as it stands now, would be a minor bump
> of
> > > > Spring Boot.
> > > >
> > > > We need to help the rest of the Grails ecosystem to catch up as well.
> > > > I'm also pretty certain there will be much maintenance work on
> Grails 8.
> > > >
> > > > I think we should release Grails 9.0.0-M1 with Groovy 6 (indy-on)
> with
> > > > Spring Boot 4.2-M2 and start testing end applications early against
> > > > that.
> > > >
> > > > As was the case for Grails 8, I'm sure there are also many great
> ideas
> > > > and features that need time to develop, polish, review and test
> before
> > > > going into a major release.
> > > >
> > > > Spring Boot RC1 is scheduled for October 22 which historically has
> > > > meant a GA one month later. That schedule has been in flux but it
> > > > seems the Spring team is trying to get back on track:
> > > >
> https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> > > >
> > > > Also important to factor in is the extra OSS support time of Spring
> > > > Boot for Grails 9.
> > > >
> > > > If Spring Boot 4.2 is released late November, which my guess it will
> > > > be, we will have shot ourselves in the foot, doing a Grails 9 with
> > > > Boot 4.1.
> > > >
> > > > That Groovy master is already on Groovy 7 is to my understanding just
> > > > how that project works.
> > > > As soon as Groovy 6 was released, it became a maintenance branch, and
> > > > only gets backport fixes from master.
> > > >
> > > > /Mattias
> > > >
> > > >
> > > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <
> jamesfredley@apache.org>:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > This is a follow-up to the earlier thread and to today's weekly
> meeting.
> > > > > This is a discuss thread, not a vote. The goal is to settle the
> language
> > > > > for a follow-up [VOTE] on the next several Grails lines.
> > > > >
> > > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward
> Groovy 6 is
> > > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy
> 7 work
> > > > > has already started: https://github.com/apache/groovy
> > > > >
> > > > > Please comment on the plan and on the wording. If you want to
> change the
> > > > > language, copy the whole proposal block below, paste it into your
> reply,
> > > > > and edit it there. Do not send a partial rewrite or a diff of a
> > > > > sentence. A full replacement block is what we will carry into the
> vote.
> > > > > If you agree with the block as written, a +1 on this thread is
> enough.
> > > > > Discussion on this thread is not a binding vote.
> > > > >
> > > > > PROPOSAL (copy this whole block if you want to change the language)
> > > > >
> > > > > 1. Grails 9.0.x
> > > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > > > > 2. Do not release 8.1.x. Skip that line.
> > > > > 3. Ship 9.0.x as a lighter release: bring Grails current with
> > > > > Groovy, without waiting on the next Spring Boot line.
> > > > > 4. Base it on Groovy 6.
> > > > > 5. Turn invokedynamic on.
> > > > > 1. Turning invokedynamic off is not a viable default. In
> Groovy
> > > > > 6.0.0 the classic call-site implementation has moved out of
> groovy-core
> > > > > into the separate groovy-callsite module, and that surface is on a
> path
> > > > > to deprecation. Core dispatch already uses invokedynamic.
> > > > > 6. Target 9.0.0 for the end of November 2026.
> > > > > 7. This release catches Grails up to Groovy. Apache Groovy 7
> work
> > > > > has already started: https://github.com/apache/groovy
> > > > >
> > > > > 2. Grails 10 (the line previously discussed as 9.1.x)
> > > > > 1. Rename the planned 9.1.x line to 10.
> > > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > > > > 3. Target 2027 Q1. Aim to release within one month of Spring
> Boot
> > > > > 4.2. That window is tight because of existing time commitments.
> > > > > 4. Use the major version bump so the release can carry material
> > > > > breaking changes and move the framework forward.
> > > > >
> > > > >
> > > > > James
> > > >
> >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Fredley <ja...@apache.org>.
Spring Boot 4.2.0 will likely come at the earliest Dec 20 2026, which is 6 months after 4.1.0. https://endoflife.date/spring-boot
Since that is Christmas, Jan is more likely.
My #1 item on this discussion is getting Grails 9.0.0 on Groovy 6 out soon and not waiting until Feb or March, so we can catch up to Groovy.
My #2 is trying to avoid supporting Spring Boot 4.2.x on Groovy 6 and Groovy 5.
The Grails 10.0.x vs 9.1.x version number is less important for me
James
On 2026/10/08 17:41:45 Mattias Reichel wrote:
> Hi James, it seems we are not understanding each other.
>
> I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
> I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and Spring
> Boot 4.2 right away.
> There we will be current and up-to-date and able to test everything.
>
> Why would it be January before we can adopt Spring Boot 4.2 when we
> can start testing it on M2 today and RC1 in a couple of weeks.
>
> /Mattias
>
>
> Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <jd...@apache.org>:
> >
> > Hi Mattias,
> >
> > Our release policy says we can't update on minor versions, if we could we could technically make 8.1 have Groovy 6 support. The reason a major is being proposed is because we're trying to follow our release policy.
> >
> > It will also likely be January before we can adopt Spring 4.2. If we wait to put groovy in, 4 months will have passed and major Groovy development will have started back up again. The reason to get on Groovy faster is so that we can be doing development while they are. We have been 2 versions behind to date and I'm skeptical we'll catch up if we wait to release support for Groovy 6. Based on what I've already found with 5, I'm worried further language decisions will be made prior to our adoption and it will be too late to change them by the time we find them.
> >
> > From a support perspective, support ends on 4.1 in Summer 2027 and for 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6 months of additional support, so I wouldn't consider 4.2 a minor.
> >
> > What's being proposed is to skip / jump ahead so we don't stay behind.
> >
> > -James
> >
> > On 2026/10/08 08:15:41 Mattias Reichel wrote:
> > > My feeling is that with this plan we are moving too fast with little gain.
> > > I fail to see the up-sides of doing this, but I'm probably missing something.
> > >
> > > From a user perspective I think it would be strange that the main
> > > selling point of Grails 10, as it stands now, would be a minor bump of
> > > Spring Boot.
> > >
> > > We need to help the rest of the Grails ecosystem to catch up as well.
> > > I'm also pretty certain there will be much maintenance work on Grails 8.
> > >
> > > I think we should release Grails 9.0.0-M1 with Groovy 6 (indy-on) with
> > > Spring Boot 4.2-M2 and start testing end applications early against
> > > that.
> > >
> > > As was the case for Grails 8, I'm sure there are also many great ideas
> > > and features that need time to develop, polish, review and test before
> > > going into a major release.
> > >
> > > Spring Boot RC1 is scheduled for October 22 which historically has
> > > meant a GA one month later. That schedule has been in flux but it
> > > seems the Spring team is trying to get back on track:
> > > https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> > >
> > > Also important to factor in is the extra OSS support time of Spring
> > > Boot for Grails 9.
> > >
> > > If Spring Boot 4.2 is released late November, which my guess it will
> > > be, we will have shot ourselves in the foot, doing a Grails 9 with
> > > Boot 4.1.
> > >
> > > That Groovy master is already on Groovy 7 is to my understanding just
> > > how that project works.
> > > As soon as Groovy 6 was released, it became a maintenance branch, and
> > > only gets backport fixes from master.
> > >
> > > /Mattias
> > >
> > >
> > > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <ja...@apache.org>:
> > > >
> > > > Hi all,
> > > >
> > > > This is a follow-up to the earlier thread and to today's weekly meeting.
> > > > This is a discuss thread, not a vote. The goal is to settle the language
> > > > for a follow-up [VOTE] on the next several Grails lines.
> > > >
> > > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
> > > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
> > > > has already started: https://github.com/apache/groovy
> > > >
> > > > Please comment on the plan and on the wording. If you want to change the
> > > > language, copy the whole proposal block below, paste it into your reply,
> > > > and edit it there. Do not send a partial rewrite or a diff of a
> > > > sentence. A full replacement block is what we will carry into the vote.
> > > > If you agree with the block as written, a +1 on this thread is enough.
> > > > Discussion on this thread is not a binding vote.
> > > >
> > > > PROPOSAL (copy this whole block if you want to change the language)
> > > >
> > > > 1. Grails 9.0.x
> > > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > > > 2. Do not release 8.1.x. Skip that line.
> > > > 3. Ship 9.0.x as a lighter release: bring Grails current with
> > > > Groovy, without waiting on the next Spring Boot line.
> > > > 4. Base it on Groovy 6.
> > > > 5. Turn invokedynamic on.
> > > > 1. Turning invokedynamic off is not a viable default. In Groovy
> > > > 6.0.0 the classic call-site implementation has moved out of groovy-core
> > > > into the separate groovy-callsite module, and that surface is on a path
> > > > to deprecation. Core dispatch already uses invokedynamic.
> > > > 6. Target 9.0.0 for the end of November 2026.
> > > > 7. This release catches Grails up to Groovy. Apache Groovy 7 work
> > > > has already started: https://github.com/apache/groovy
> > > >
> > > > 2. Grails 10 (the line previously discussed as 9.1.x)
> > > > 1. Rename the planned 9.1.x line to 10.
> > > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > > > 3. Target 2027 Q1. Aim to release within one month of Spring Boot
> > > > 4.2. That window is tight because of existing time commitments.
> > > > 4. Use the major version bump so the release can carry material
> > > > breaking changes and move the framework forward.
> > > >
> > > >
> > > > James
> > >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by Mattias Reichel <ma...@apache.org>.
Hi James, it seems we are not understanding each other.
I'm not suggesting we upgrade to Groovy 6 in Grails 8.1.
I am suggesting we release Grails 9.0.0-M1 with Groovy 6 and Spring
Boot 4.2 right away.
There we will be current and up-to-date and able to test everything.
Why would it be January before we can adopt Spring Boot 4.2 when we
can start testing it on M2 today and RC1 in a couple of weeks.
/Mattias
Den tors 8 okt. 2026 kl 18:39 skrev James Daugherty <jd...@apache.org>:
>
> Hi Mattias,
>
> Our release policy says we can't update on minor versions, if we could we could technically make 8.1 have Groovy 6 support. The reason a major is being proposed is because we're trying to follow our release policy.
>
> It will also likely be January before we can adopt Spring 4.2. If we wait to put groovy in, 4 months will have passed and major Groovy development will have started back up again. The reason to get on Groovy faster is so that we can be doing development while they are. We have been 2 versions behind to date and I'm skeptical we'll catch up if we wait to release support for Groovy 6. Based on what I've already found with 5, I'm worried further language decisions will be made prior to our adoption and it will be too late to change them by the time we find them.
>
> From a support perspective, support ends on 4.1 in Summer 2027 and for 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6 months of additional support, so I wouldn't consider 4.2 a minor.
>
> What's being proposed is to skip / jump ahead so we don't stay behind.
>
> -James
>
> On 2026/10/08 08:15:41 Mattias Reichel wrote:
> > My feeling is that with this plan we are moving too fast with little gain.
> > I fail to see the up-sides of doing this, but I'm probably missing something.
> >
> > From a user perspective I think it would be strange that the main
> > selling point of Grails 10, as it stands now, would be a minor bump of
> > Spring Boot.
> >
> > We need to help the rest of the Grails ecosystem to catch up as well.
> > I'm also pretty certain there will be much maintenance work on Grails 8.
> >
> > I think we should release Grails 9.0.0-M1 with Groovy 6 (indy-on) with
> > Spring Boot 4.2-M2 and start testing end applications early against
> > that.
> >
> > As was the case for Grails 8, I'm sure there are also many great ideas
> > and features that need time to develop, polish, review and test before
> > going into a major release.
> >
> > Spring Boot RC1 is scheduled for October 22 which historically has
> > meant a GA one month later. That schedule has been in flux but it
> > seems the Spring team is trying to get back on track:
> > https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
> >
> > Also important to factor in is the extra OSS support time of Spring
> > Boot for Grails 9.
> >
> > If Spring Boot 4.2 is released late November, which my guess it will
> > be, we will have shot ourselves in the foot, doing a Grails 9 with
> > Boot 4.1.
> >
> > That Groovy master is already on Groovy 7 is to my understanding just
> > how that project works.
> > As soon as Groovy 6 was released, it became a maintenance branch, and
> > only gets backport fixes from master.
> >
> > /Mattias
> >
> >
> > Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <ja...@apache.org>:
> > >
> > > Hi all,
> > >
> > > This is a follow-up to the earlier thread and to today's weekly meeting.
> > > This is a discuss thread, not a vote. The goal is to settle the language
> > > for a follow-up [VOTE] on the next several Grails lines.
> > >
> > > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
> > > already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
> > > has already started: https://github.com/apache/groovy
> > >
> > > Please comment on the plan and on the wording. If you want to change the
> > > language, copy the whole proposal block below, paste it into your reply,
> > > and edit it there. Do not send a partial rewrite or a diff of a
> > > sentence. A full replacement block is what we will carry into the vote.
> > > If you agree with the block as written, a +1 on this thread is enough.
> > > Discussion on this thread is not a binding vote.
> > >
> > > PROPOSAL (copy this whole block if you want to change the language)
> > >
> > > 1. Grails 9.0.x
> > > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > > 2. Do not release 8.1.x. Skip that line.
> > > 3. Ship 9.0.x as a lighter release: bring Grails current with
> > > Groovy, without waiting on the next Spring Boot line.
> > > 4. Base it on Groovy 6.
> > > 5. Turn invokedynamic on.
> > > 1. Turning invokedynamic off is not a viable default. In Groovy
> > > 6.0.0 the classic call-site implementation has moved out of groovy-core
> > > into the separate groovy-callsite module, and that surface is on a path
> > > to deprecation. Core dispatch already uses invokedynamic.
> > > 6. Target 9.0.0 for the end of November 2026.
> > > 7. This release catches Grails up to Groovy. Apache Groovy 7 work
> > > has already started: https://github.com/apache/groovy
> > >
> > > 2. Grails 10 (the line previously discussed as 9.1.x)
> > > 1. Rename the planned 9.1.x line to 10.
> > > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > > 3. Target 2027 Q1. Aim to release within one month of Spring Boot
> > > 4.2. That window is tight because of existing time commitments.
> > > 4. Use the major version bump so the release can carry material
> > > breaking changes and move the framework forward.
> > >
> > >
> > > James
> >
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Daugherty <jd...@apache.org>.
Hi Mattias,
Our release policy says we can't update on minor versions, if we could we could technically make 8.1 have Groovy 6 support. The reason a major is being proposed is because we're trying to follow our release policy.
It will also likely be January before we can adopt Spring 4.2. If we wait to put groovy in, 4 months will have passed and major Groovy development will have started back up again. The reason to get on Groovy faster is so that we can be doing development while they are. We have been 2 versions behind to date and I'm skeptical we'll catch up if we wait to release support for Groovy 6. Based on what I've already found with 5, I'm worried further language decisions will be made prior to our adoption and it will be too late to change them by the time we find them.
From a support perspective, support ends on 4.1 in Summer 2027 and for 4.2 at the end of year on 2027. Jumping to 10 to 4.2 grants 6 months of additional support, so I wouldn't consider 4.2 a minor.
What's being proposed is to skip / jump ahead so we don't stay behind.
-James
On 2026/10/08 08:15:41 Mattias Reichel wrote:
> My feeling is that with this plan we are moving too fast with little gain.
> I fail to see the up-sides of doing this, but I'm probably missing something.
>
> From a user perspective I think it would be strange that the main
> selling point of Grails 10, as it stands now, would be a minor bump of
> Spring Boot.
>
> We need to help the rest of the Grails ecosystem to catch up as well.
> I'm also pretty certain there will be much maintenance work on Grails 8.
>
> I think we should release Grails 9.0.0-M1 with Groovy 6 (indy-on) with
> Spring Boot 4.2-M2 and start testing end applications early against
> that.
>
> As was the case for Grails 8, I'm sure there are also many great ideas
> and features that need time to develop, polish, review and test before
> going into a major release.
>
> Spring Boot RC1 is scheduled for October 22 which historically has
> meant a GA one month later. That schedule has been in flux but it
> seems the Spring team is trying to get back on track:
> https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
>
> Also important to factor in is the extra OSS support time of Spring
> Boot for Grails 9.
>
> If Spring Boot 4.2 is released late November, which my guess it will
> be, we will have shot ourselves in the foot, doing a Grails 9 with
> Boot 4.1.
>
> That Groovy master is already on Groovy 7 is to my understanding just
> how that project works.
> As soon as Groovy 6 was released, it became a maintenance branch, and
> only gets backport fixes from master.
>
> /Mattias
>
>
> Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <ja...@apache.org>:
> >
> > Hi all,
> >
> > This is a follow-up to the earlier thread and to today's weekly meeting.
> > This is a discuss thread, not a vote. The goal is to settle the language
> > for a follow-up [VOTE] on the next several Grails lines.
> >
> > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
> > already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
> > has already started: https://github.com/apache/groovy
> >
> > Please comment on the plan and on the wording. If you want to change the
> > language, copy the whole proposal block below, paste it into your reply,
> > and edit it there. Do not send a partial rewrite or a diff of a
> > sentence. A full replacement block is what we will carry into the vote.
> > If you agree with the block as written, a +1 on this thread is enough.
> > Discussion on this thread is not a binding vote.
> >
> > PROPOSAL (copy this whole block if you want to change the language)
> >
> > 1. Grails 9.0.x
> > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > 2. Do not release 8.1.x. Skip that line.
> > 3. Ship 9.0.x as a lighter release: bring Grails current with
> > Groovy, without waiting on the next Spring Boot line.
> > 4. Base it on Groovy 6.
> > 5. Turn invokedynamic on.
> > 1. Turning invokedynamic off is not a viable default. In Groovy
> > 6.0.0 the classic call-site implementation has moved out of groovy-core
> > into the separate groovy-callsite module, and that surface is on a path
> > to deprecation. Core dispatch already uses invokedynamic.
> > 6. Target 9.0.0 for the end of November 2026.
> > 7. This release catches Grails up to Groovy. Apache Groovy 7 work
> > has already started: https://github.com/apache/groovy
> >
> > 2. Grails 10 (the line previously discussed as 9.1.x)
> > 1. Rename the planned 9.1.x line to 10.
> > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > 3. Target 2027 Q1. Aim to release within one month of Spring Boot
> > 4.2. That window is tight because of existing time commitments.
> > 4. Use the major version bump so the release can carry material
> > breaking changes and move the framework forward.
> >
> >
> > James
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by Mattias Reichel <ma...@apache.org>.
My feeling is that with this plan we are moving too fast with little gain.
I fail to see the up-sides of doing this, but I'm probably missing something.
From a user perspective I think it would be strange that the main
selling point of Grails 10, as it stands now, would be a minor bump of
Spring Boot.
We need to help the rest of the Grails ecosystem to catch up as well.
I'm also pretty certain there will be much maintenance work on Grails 8.
I think we should release Grails 9.0.0-M1 with Groovy 6 (indy-on) with
Spring Boot 4.2-M2 and start testing end applications early against
that.
As was the case for Grails 8, I'm sure there are also many great ideas
and features that need time to develop, polish, review and test before
going into a major release.
Spring Boot RC1 is scheduled for October 22 which historically has
meant a GA one month later. That schedule has been in flux but it
seems the Spring team is trying to get back on track:
https://github.com/spring-projects/spring-boot/issues/50902#issuecomment-5914928034
Also important to factor in is the extra OSS support time of Spring
Boot for Grails 9.
If Spring Boot 4.2 is released late November, which my guess it will
be, we will have shot ourselves in the foot, doing a Grails 9 with
Boot 4.1.
That Groovy master is already on Groovy 7 is to my understanding just
how that project works.
As soon as Groovy 6 was released, it became a maintenance branch, and
only gets backport fixes from master.
/Mattias
Den ons 7 okt. 2026 kl 17:57 skrev James Fredley <ja...@apache.org>:
>
> Hi all,
>
> This is a follow-up to the earlier thread and to today's weekly meeting.
> This is a discuss thread, not a vote. The goal is to settle the language
> for a follow-up [VOTE] on the next several Grails lines.
>
> Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
> already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
> has already started: https://github.com/apache/groovy
>
> Please comment on the plan and on the wording. If you want to change the
> language, copy the whole proposal block below, paste it into your reply,
> and edit it there. Do not send a partial rewrite or a diff of a
> sentence. A full replacement block is what we will carry into the vote.
> If you agree with the block as written, a +1 on this thread is enough.
> Discussion on this thread is not a binding vote.
>
> PROPOSAL (copy this whole block if you want to change the language)
>
> 1. Grails 9.0.x
> 1. Merge the 8.1.x branch up into the 9.0.x branch.
> 2. Do not release 8.1.x. Skip that line.
> 3. Ship 9.0.x as a lighter release: bring Grails current with
> Groovy, without waiting on the next Spring Boot line.
> 4. Base it on Groovy 6.
> 5. Turn invokedynamic on.
> 1. Turning invokedynamic off is not a viable default. In Groovy
> 6.0.0 the classic call-site implementation has moved out of groovy-core
> into the separate groovy-callsite module, and that surface is on a path
> to deprecation. Core dispatch already uses invokedynamic.
> 6. Target 9.0.0 for the end of November 2026.
> 7. This release catches Grails up to Groovy. Apache Groovy 7 work
> has already started: https://github.com/apache/groovy
>
> 2. Grails 10 (the line previously discussed as 9.1.x)
> 1. Rename the planned 9.1.x line to 10.
> 2. Base it on Groovy 6 and Spring Boot 4.2.
> 3. Target 2027 Q1. Aim to release within one month of Spring Boot
> 4.2. That window is tight because of existing time commitments.
> 4. Use the major version bump so the release can carry material
> breaking changes and move the framework forward.
>
>
> James
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by Gianluca Sartori <g....@gmail.com>.
It does make sense to me
Gianluca Sartori
--
https://dueuno.com
On Tue, 13 Oct 2026 at 12:13, James Daugherty <jd...@apache.org> wrote:
> The latest proposal seems to be:
> 1. release 8.1 (target ??)
> 2. have 9 be 4.1 & Groovy 6 (Target Nov)
> 3. have 9.1 be 4.2; start a milestone soon with a target of when or
> shortly after spring releases
>
> Does this sound right?
>
> On 2026-10-07 15:56 UTC James Fredley wrote:
> > Hi all,
> >
> > This is a follow-up to the earlier thread and to today's weekly meeting.
> > This is a discuss thread, not a vote. The goal is to settle the language
> > for a follow-up [VOTE] on the next several Grails lines.
> >
> > Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
> > already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
> > has already started: https://github.com/apache/groovy
> >
> > Please comment on the plan and on the wording. If you want to change the
> > language, copy the whole proposal block below, paste it into your reply,
> > and edit it there. Do not send a partial rewrite or a diff of a
> > sentence. A full replacement block is what we will carry into the vote.
> > If you agree with the block as written, a +1 on this thread is enough.
> > Discussion on this thread is not a binding vote.
> >
> > PROPOSAL (copy this whole block if you want to change the language)
> >
> > 1. Grails 9.0.x
> > 1. Merge the 8.1.x branch up into the 9.0.x branch.
> > 2. Do not release 8.1.x. Skip that line.
> > 3. Ship 9.0.x as a lighter release: bring Grails current with
> > Groovy, without waiting on the next Spring Boot line.
> > 4. Base it on Groovy 6.
> > 5. Turn invokedynamic on.
> > 1. Turning invokedynamic off is not a viable default. In Groovy
> > 6.0.0 the classic call-site implementation has moved out of groovy-core
> > into the separate groovy-callsite module, and that surface is on a path
> > to deprecation. Core dispatch already uses invokedynamic.
> > 6. Target 9.0.0 for the end of November 2026.
> > 7. This release catches Grails up to Groovy. Apache Groovy 7 work
> > has already started: https://github.com/apache/groovy
> >
> > 2. Grails 10 (the line previously discussed as 9.1.x)
> > 1. Rename the planned 9.1.x line to 10.
> > 2. Base it on Groovy 6 and Spring Boot 4.2.
> > 3. Target 2027 Q1. Aim to release within one month of Spring Boot
> > 4.2. That window is tight because of existing time commitments.
> > 4. Use the major version bump so the release can carry material
> > breaking changes and move the framework forward.
> >
> >
> > James
> >
>
Re: [DISCUSS] Grails 9.0 and 10: skipping 8.1, Groovy 6 by end of November, Spring Boot 4.2 as 10 in 2027 Q1
Posted by James Daugherty <jd...@apache.org>.
The latest proposal seems to be:
1. release 8.1 (target ??)
2. have 9 be 4.1 & Groovy 6 (Target Nov)
3. have 9.1 be 4.2; start a milestone soon with a target of when or shortly after spring releases
Does this sound right?
On 2026-10-07 15:56 UTC James Fredley wrote:
> Hi all,
>
> This is a follow-up to the earlier thread and to today's weekly meeting.
> This is a discuss thread, not a vote. The goal is to settle the language
> for a follow-up [VOTE] on the next several Grails lines.
>
> Grails 8.0.0 is out (Groovy 5, Spring Boot 4.1). Work toward Groovy 6 is
> already on the 9.0.x line, and Apache Groovy 6.0.0 is out. Groovy 7 work
> has already started: https://github.com/apache/groovy
>
> Please comment on the plan and on the wording. If you want to change the
> language, copy the whole proposal block below, paste it into your reply,
> and edit it there. Do not send a partial rewrite or a diff of a
> sentence. A full replacement block is what we will carry into the vote.
> If you agree with the block as written, a +1 on this thread is enough.
> Discussion on this thread is not a binding vote.
>
> PROPOSAL (copy this whole block if you want to change the language)
>
> 1. Grails 9.0.x
> 1. Merge the 8.1.x branch up into the 9.0.x branch.
> 2. Do not release 8.1.x. Skip that line.
> 3. Ship 9.0.x as a lighter release: bring Grails current with
> Groovy, without waiting on the next Spring Boot line.
> 4. Base it on Groovy 6.
> 5. Turn invokedynamic on.
> 1. Turning invokedynamic off is not a viable default. In Groovy
> 6.0.0 the classic call-site implementation has moved out of groovy-core
> into the separate groovy-callsite module, and that surface is on a path
> to deprecation. Core dispatch already uses invokedynamic.
> 6. Target 9.0.0 for the end of November 2026.
> 7. This release catches Grails up to Groovy. Apache Groovy 7 work
> has already started: https://github.com/apache/groovy
>
> 2. Grails 10 (the line previously discussed as 9.1.x)
> 1. Rename the planned 9.1.x line to 10.
> 2. Base it on Groovy 6 and Spring Boot 4.2.
> 3. Target 2027 Q1. Aim to release within one month of Spring Boot
> 4.2. That window is tight because of existing time commitments.
> 4. Use the major version bump so the release can carry material
> breaking changes and move the framework forward.
>
>
> James
>