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 <[email protected]> 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 < > [email protected]> > > 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 <[email protected] > > > > > 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 < > > >> [email protected]>: > > >> > > > >> > > Then, the common ground would be 9.0 and 9.1? > > >> > > > > >> > > Den tors 8 okt. 2026 20:05James Fredley <[email protected]> > > >> 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 < > > >> > > > [email protected]>: > > >> > > > > > > > >> > > > > > 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 < > > >> > > > [email protected]>: > > >> > > > > > > > > > >> > > > > > > > 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 > > >> > > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > >
