First, some data points: * Groovy 6 support in Spock landed yesterday with version 2.5. * IntelliJ still does not support Groovy 6 ( https://youtrack.jetbrains.com/projects/IDEA/issues/IDEA-390510/Support-Groovy-6.0 ).
There are 3 features in 8.1.x that are not in 8.0: * Startup Progress (mentioned in this thread) * RxGORM * GrailsAppBuilder (mostly clean up related) The rest of 8.1.x looks to be tests & refactoring. I understand the desire to get Groovy 6 out sooner - Mattias & I questioned if we could get it into 8.0. He even backported the majority of the Groovy 6 changes into 8.0 in the event that Spock released in time. With that said, I've struggled to get reviewers on code reviews and in just the last week, I've worked through 55+ PRs. I do NOT want to set an aggressive target that is going to mean doing code reviews non-stop - mostly because of personal obligations I have in the next month. I get that we're very close to 4.2 & we are eager to quickly follow Spring's releases, but we're still catching up in my mind. Until we have more people offering to do releases, helping with maintenance, and doing PR reviews, I'm not a fan of this schedule. I'm with Mattias: let's do a 9.0.0-M1 now. I think we shouldn't target 9.x until January or February of next year. This allows us to: 1. have time to test on the new release (I propose a minimum 2 weeks each milestone) 2. perform bug fixes for 8.0 (we know there's a lot with the new hibernate changes) 3. release an 8.1 (I'm not a fan of foregoing these releases) I also think we should set cut off dates for new features - we shouldn't be adding them a week or 2 before release. -James On Tue, Oct 6, 2026 at 4:33 AM Mattias Reichel <[email protected]> wrote: > Based on our experience with past releases, I think a late November or > early December release of Grails 9 is optimistic [1]. > > I suggest we publish 9.0.0-M1 now with Groovy 6 and Spring Boot > 4.2-M2. That would let us gather feedback on both upgrades early and > work towards including Spring Boot 4.2 in 9.0. > > I’m happy to skip minor releases for Grails 8, but we should > acknowledge the trade-off: users would remain on the 8.0 feature set > until Grails 9 is released. > > We should also clarify our release and support policy, particularly > when support for a minor release ends and users are expected to move > to a newer minor. That would help set expectations and reduce the > number of release lines we need to maintain. > > [1] https://lists.apache.org/thread.html/hxbb31nvj6tr72h6ffgrxmogkoxdvolg > > Den mån 5 okt. 2026 kl 03:06 skrev James Fredley <[email protected] > >: > > > > Hi everyone, > > > > The 8.0.0 vote is out, which is is an AWESOME accomplishment. > > > > While that finishes, I want to discuss what we do next, before we spend > > time on the wrong branch. > > > > Proposal: do not release an 8.1.x on Spring Boot 4.2 in Q1 2027. Ship > > 8.0.x, move straight to 9.0.x on Groovy 6 (snapshots already exist), and > > pick up Spring Boot 4.2 in a 9.1.x release after that GA is out. > > > > The schedule would look like this: > > > > - 8.0.0 on Spring Boot 4.1 and Groovy 5 - now > > - 9.0.0 on Spring Boot 4.1 and Groovy 6 targets late November or early > > December. Those snapshots are already running. > > - I expect Spring Boot 4.2 GA around Christmas or early January rather > > than the usual late November window. 4.1 landed in June, about a month > > late. Spring Boot 4.2.0-M2 shipped on 24 September. The 4.2.0-RC1 > > milestone is 29 of 30 issues closed > > (https://github.com/spring-projects/spring-boot/milestone/433). The > > 4.2.0 GA milestone is open, but Spring has not set a due date > > (https://github.com/spring-projects/spring-boot/milestone/434). > > - After Spring Boot 4.2 GA, we release 9.1 on top of 9.0 in Q1 2027 > > - 8.1 stays on the shelf unless we find a real reason to release it. > > > > Two release trains are driving this. We still cut a Grails major when > > Spring Boot cuts a major. Groovy now looks like it will cut a major > > about once a year, and that will also be a Grails major. I do not think > > we should also keep chasing each Spring Boot minor on the old Groovy > > line. Cleaner cutoff: a Grails line stays on the Spring Boot minor it > > shipped with, and the next Spring Boot minor lands on the new Groovy > major. > > > > The merge cost is the main reason to skip an 8.1 release. Spring Boot > > 4.2 changes will not apply cleanly to the Groovy 6 work already on > > 9.0.x. They will apply to 9.1, which is where we want them. Doing that > > upgrade for an 8.1 release and again for 9.1 is the same work twice. > > Those changes might get merged to the wrong line, replayed, or dropped. > > We could try to keep lines working on both Spring Boot 4.1 (Grails 8.0.x > > and 9.0.x) and 4.2(Grails 8.1.x and 9.1.x), but that is not worth it for > > a line most people will leave quickly or skip entirely. > > > > 9.0 should be a short release. If it lands in late November or early > > December, 9.1 can follow soon after the Spring Boot 4.2 GA in Q1 2027. > > Users will likely move to latest Groovy, especially with the performance > > boost. > > > > This does not end 8.0.x. Patch releases on 8.0.x continue as usual. The > > only question is whether we spend a minor release moving Groovy 5 onto > > Spring Boot 4.2. > > > > Does this match what others expect for the next few months? > > > > Reasons that would change my mind: users who cannot move to Groovy 6, a > > compatibility promise we have already made, or a merge approach that is > > cheaper than it looks. > > > > Thanks, > > James Fredley > > VP, Apache Grails > > PMC Chair >
