BTW, it was not my intention to take anything away from the tremendous work you’ve all done. I was just trying to share a different point of view for the sake of the discussion.
I’ve read my email again and I sound like a dick, it was not intentional, sorry about that. Gianluca Sartori -- https://dueuno.com On Mon, 5 Oct 2026 at 14:50, James Fredley <[email protected]> wrote: > https://grails.apache.org/support-schedule.html lists the versions > > 7.x.x were extended a bit, as was possible since Spring Boot 3.5.x was > EOL, but are now likely at the end since 8.0.0 will be out this week. > > James > > On 2026/10/05 06:33:38 Gianluca Sartori wrote: > > As a user, > > > > I would keep my apps to Grails 7/Groovy 4, just because that’s the latest > > release we moved to, and wait till Grails 9/Groovy 6 is out, just because > > of the performance gain. > > > > I am also not entirely sure why we are keeping three Grails 7.x releases. > > That also from a user perspective is a bit confusing: what version > should I > > use? Why? That’s not immediately clear from the website. > > > > It is my personal opinion that the only reason to maintain a specific > > Grails version would be to enable people with JVM restrictions to use > > Grails (eg: Grails 5 -> Java 8, Grails 7 -> Java 17, etc). > > > > But given the speed the underlying technologies are progressing nowadays, > > who wants to maintain a monolithic app with an old and UNSAFE stack? > > > > UNSAFE is something the business understands, it’s a driver to move ahead > > with the underlying technologies like Java and Spring. > > > > Since each Grails new release comes with refactoring COSTS, they must be > > justified somehow. > > > > From a business point of view there is no reason to move to Grails > 8/Groovy > > 5 when we have Grails 9/Groovy 6 in a six months timeframe and with much > > added value respect to Grails 8/Groovy 5. > > > > On a side note, we are almost ready to release Dueuno 4/Grails 8 along > with > > the latest application we are working on. But if we manage to skip that > and > > jump straight to a Dueuno 4/Grails 9/Groovy 6 with noticeably improved > > performance, that would be better. > > > > > > Gianluca Sartori > > -- > > https://dueuno.com > > > > On Mon, 5 Oct 2026 at 03:04, James Fredley <[email protected]> > 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 > > > > > >
