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
