+1 (binding)
On 2026-10-18 13:02 UTC James Fredley wrote: > Hi Everyone, > > Priority is Grails 9.0.x by the end of November 2026 on Groovy 6 to > catch up. Follow with a quick 8.1.x on Spring Boot 4.1. Do the Spring > Boot 4.2 upgrade as 9.1.x on the Groovy 6 line. Treat 8.2.x as optional > and not preferred. Start a Grails 10 branch on Groovy 7 in the next few > months. Major versions will be driven by Spring Boot majors, Groovy > majors, or extreme breaking changes, targeting roughly one major per year. > > VERSIONING PRINCIPLES > > Major Grails versions are triggered by: > 1. Spring Boot / Spring Framework major releases (e.g. Spring Boot 5). > 2. Groovy major releases (now on an annual cadence). > 3. Extreme breaking changes > > Prefer to align the third category with the first two. This produces at > least one major version per year going forward (an acceleration from the > historical pace). Spring Boot ships a new major or minor roughly every 6 > months (typically May and November). Majors have historically landed > every 4 or 5 releases, aligned with Jakarta EE bumps, which are on a 2 > year schedule. When a Spring Boot major and a Groovy major coincide, we > will try to line them up so we do not ship two Grails majors in the same > year, going forward. > > Our existing versioning policy is documented in RELEASE.md (Appendix: > Versioning): > > https://github.com/apache/grails-core/blob/8.0.x/RELEASE.md > > As Apache Grails is built on the Spring Framework (Spring Boot), we > follow the Spring release versioning scheme and also release soon after > a Spring Boot release. > > The versioning scheme format is MAJOR.MINOR.PATCH[-MODIFIER] where: > - MAJOR: Indicates significant changes that may include breaking > changes. If incremented, may involve a significant amount of work to > upgrade. > - MINOR: Represents new features that are backward compatible. If > incremented, should involve little to no work to upgrade. > - PATCH: Refers to backward-compatible bug fixes. If incremented, should > involve no work. > - MODIFIER: Optional (e.g. -M<COUNT>, -RC<COUNT>, -SNAPSHOT). Final > releases have no modifier. > > MINOR VERSIONS > > Minor versions (x.y) are used for new features that remain backward > compatible and should involve little to no work to upgrade. In this plan: > - 8.1.x is a minor on the current Spring Boot 4.1 line for low-risk, > ready changes. > - 9.1.x is a minor on the Groovy 6 line for the Spring Boot 4.2 upgrade > so the major version bump is reserved for material breaking changes later. > - We prefer to use minors for Spring Boot upgrades that do not force > extreme breaking changes, keeping majors aligned with Groovy majors, > Spring Boot majors, or truly breaking changes. > > PROPOSED PLAN > > Most of these branches already exist and the work started. > > 1. Grails 9.0.x – Groovy 6 catch-up (priority) > 1. Base it on Groovy 6. > 2. Enable invokedynamic by default. > 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 is on a path to > deprecation. Core dispatch already uses invokedynamic. > 3. Include the two PRs from Scott related to JSON changes on Spring > Boot 4.1, plus any other minor and quick PRs that can be merged in time. > 4. Target 9.0.0 for the end of November 2026. > 5. Ship it as a focused release that brings Grails current with > Groovy 6 without waiting for the next Spring Boot line. Apache Groovy 7 > work has already started: https://github.com/apache/groovy > > 2. Grails 8.1.x – Quick release on Spring Boot 4.1 > 1. Base it on 8.0.x. > 2. Keep it on Spring Boot 4.1. > 3. Release it rather quickly (near-term). > 4. Include only low-risk, ready changes that do not delay the release. > > 3. Grails 9.1.x – Spring Boot 4.2 upgrade > 1. Base it on Groovy 6 and Spring Boot 4.2. > 2. Target 2027 Q1. Aim to release within one month of Spring Boot > 4.2 GA. > 3. Use this minor line for the Spring Boot 4.2 upgrade so the major > version bump is reserved for material breaking changes later. > 4. Set a firm target date to limit feature creep. > > 4. Grails 8.2.x – Optional / not preferred > 1. Would be based on Spring Boot 4.2 (still on Groovy 5). > 2. Small chance of doing this release. Preference is not to ship 8.2.x. > 3. Prefer to do the Spring Boot 4.2 upgrade on the 9.x line (Groovy > 6) so we do not support Spring Boot 4.2 on both Groovy 5 and Groovy 6. > > 5. Grails 10 (Groovy 7) – start branch soon > 1. Start the branch in the next few months. > 2. Base it on Groovy 7. > 3. Work on it in parallel with Groovy 7 development so Grails is > ready when Groovy 7 is released. > 4. Target release once Groovy 7 is released. > 5. This will be the next major, driven by the Groovy major (and > aligned with any Spring Boot major if timing works). > > The vote is open for a minimum of 72 hours and passes if a majority of > at least three +1 PMC votes are cast. > > [ ] +1 Approve the plan as described > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not approve the plan because... > > Here is my vote: > > +1 (binding) > > James Fredley >
