Scott,

Spring Boot 4.2 will not be released until the end of 2026 or beginning of 
2027, so I think it is out for Grails 9.0.x and only possible for Grails 9.1.x 
sometime in Q1 2027.  That is the main reason I wrote this post initially.

James

On 2026/10/05 17:27:33 Scott Murphy Heiberg wrote:
> We need to start pinning releases the the Spring Boot lifecycle instead of 
> playing catch up all the time.
> 
> There also needs to be time after milestones to identify issues.
> Considering we have not released even an M1 of 9, it sounds like this would 
> be rushing.
> 
> There is a dramatic swing going from 8 to 9 since we released 7 with indy 
> half baked and 8 with indy fully off.
> 9 will have indy on. This will have unknown consequences especially with 
> plugin transitions.
> 
> There should be milestone releases that allow properly testing the switch. 
> If we are going to release before 4.2.0 goes final, I feel like that will not 
> be adequate time to test.
> 
> How many major/minor version combos are we going to maintain?  We want to 
> simultaneously maintain a 9 with 4.1.x and a 9.1.x with 4.2.x?
> Who is going to merge up a 7.0.x patch and perform all the releases?
> 
> We got a lot done in 8.0.0 and it took a year.  I don't see why we can't pin 
> to Spring 4.2.0 and release a more refined product that is easier to maintain 
> in the long run.
> We should release 9.0.0-M1 now with Spring Boot 4.2.0-M2. If we do that now, 
> we can release a stable 9.0.0 with 4.2.0 within days of 4.2.0 releasing. 
> 
> -- Scott
> 
> On 2026-10-05 01:04 UTC James Fredley wrote:
> > 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
> > 
> 

Reply via email to