+1
Gianluca Sartori -- https://dueuno.com On Sun, 18 Oct 2026 at 18:48, Søren Berg Glasius <[email protected]> wrote: > +1 (binding) > > Den søn. 18. okt. 2026 kl. 15.03 skrev James Fredley < > [email protected]>: > > > 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 > > >
