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