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 > > > >
