Development workflow

The day-to-day cycle for contributing code to Spring Framework: pick up work, write the code, validate locally, send a PR, and respond to review.

Picking up work

• Issues labelled ideal-for-contribution are good places to start.
• The waiting-for-triage label means the team has not yet evaluated the issue. Do not start coding against these — your work may be moot.
• Bug fixes are easier to land than features. For features, get team alignment first.

Branching strategy

The repository uses two long-lived maintenance branches alongside main:

Branch	Purpose
main	Active development, points at the next minor (7.1.x)
7.0.x	Patches to the current GA line
6.2.x	Patches to the previous GA line (long-term support)

You should always branch from and target main. The team handles backports on merge — they will merge upward (e.g., from 6.2.x → 7.0.x → main) as needed.

Local cycle

A typical contributor session:

git fetch upstream
git checkout main
git rebase upstream/main
git checkout -b fix/gh-12345-meaningful-name

# … edit code …

./gradlew :spring-context:test          # narrow validation
./gradlew :spring-context:check         # tests + style
./gradlew check                         # full project gates (slow)

git add -p
git commit --signoff -m "Subject line under 55 chars

Body wrapped at 72.

Closes gh-12345"

git push origin fix/gh-12345-meaningful-name

Commit message conventions

From CONTRIBUTING.md:

• Subject — 55 characters or fewer, written in the imperative mood ("Fix NPE in JdbcTemplate")
• Body — wrapped at 72 characters, explains why not what
• Trailer — Closes gh-NNNN to auto-close the corresponding issue when merged
• Sign-off — Signed-off-by: First Last <email> is mandatory (Developer Certificate of Origin)

Use git log for examples — the existing history is the canonical reference for tone.

Pull request expectations

• Open against main only.
• Title mirrors the commit subject.
• Description provides context, references the issue, and lists any breaking-change implications.
• Tag CI failures — if a check fails for unrelated reasons, mention it; if your change introduced the failure, fix and re-push.
• Be responsive to review feedback. The team often asks for adjustments; rework on the same branch with normal commits, then squash before merge if asked.

What "done" looks like

A change is done when:

1. ✅ All tests pass locally (./gradlew check)
2. ✅ Nullability checks pass (io.spring.nullability plugin)
3. ✅ Checkstyle passes (./gradlew checkstyleMain checkstyleTest)
4. ✅ Javadoc compiles cleanly for any public API additions
5. ✅ The PR is reviewed and approved by a core committer
6. ✅ CI is green across all matrix entries (Linux × Java 21 × Java 25)

Only core committers merge. Community contributors should not click the merge button even if GitHub allows it.

See also

• Testing — how to add and run tests
• Tooling — what each Gradle plugin does
• Patterns and conventions — code style