Skip to content

fix(deps): hold Spring Boot/Framework/Gradle majors until starter certifies#37

Merged
jlc488 merged 1 commit into
mainfrom
fix/dependabot-hold-major-bumps
May 23, 2026
Merged

fix(deps): hold Spring Boot/Framework/Gradle majors until starter certifies#37
jlc488 merged 1 commit into
mainfrom
fix/dependabot-hold-major-bumps

Conversation

@jlc488
Copy link
Copy Markdown
Contributor

@jlc488 jlc488 commented May 23, 2026

Summary

Dependabot opened 18 individual PRs (#19-#36) to bump every demo from Spring Boot 3.5.3 → 4.0.6 (major) and Gradle wrapper 8.10.2 → 9.5.1 (major). The grouped PRs from the same run worked fine (e.g. #18 spring-boot patch/minor across 9 dirs); what didn't was that Dependabot's default group semantics exclude `version-update:semver-major`, so majors escaped grouping and landed as individual PRs per demo.

Beyond the queue noise, the real problem is that the demos must mirror the Spring Boot baseline each starter was certified against — per the easy-paging README:

Spring Boot 3.3+ on Java 21+ (built/tested against 3.5)

`easy-paging-spring-boot-starter` has not (yet) published a release certified against Spring Boot 4 / Spring Framework 7 / Jakarta EE 11. Auto-bumping demos to SB4 would silently advertise an unverified combination to anyone who clones a demo as a starting point.

Change

Adds an `ignore` block holding majors for:

Pattern Why hold
`org.springframework.boot:*` The BOM driver — moving it majors everything
`io.spring.dependency-management` Coupled to SB plugin
`org.springframework:*` Transitively pulled in; majors can land off the SB cadence
`org.springframework.cloud:*` Same
`gradle` (wrapper) Each major needs hand verification of deprecations-now-errors before going green across 9 demos

Patch/minor bumps still flow through (and group correctly — PR #18 already proved that path), so security fixes within the 3.5.x line land normally.

When to lift

When each starter publishes a SB4-compatible release line (e.g. `easy-paging-spring-boot-starter:0.5.0`), this ignore block gets relaxed for that specific starter family, and the demos get upgraded together in one intentional PR per starter — not piecemeal by a robot.

Follow-up cleanup (manual, after this merges)

Verification

Config-only change. CI `detect` job should identify zero demos changed (no `*-demo/` paths touched), build job correctly skipped.

YAML parse + structure check passed locally:

  • 9 directories preserved
  • 5 ignore rules (the new block)
  • 5 groups preserved (easy-paging, ssrf-guard, spring-boot, test-tooling, database-drivers)

Test plan

  • CI green (detect → no demos → build skipped)
  • After merge, follow up with the 4 merges + 18 closes listed above
  • Next weekly Dependabot run (next Monday 09:00 KST) does NOT re-open any SB-major or Gradle-major PRs

…tifies

After yesterday's dependabot.yml went live, Dependabot opened 18
individual PRs to bump every demo from Spring Boot 3.5.3 → 4.0.6 and
Gradle wrapper 8.10.2 → 9.5.1 (#19-#36). The grouped PRs (e.g. #18
for spring-boot patch/minor) worked correctly; what didn't was that
default group semantics excluded `version-update:semver-major`, so
major bumps escaped grouping and landed as individual PRs per demo.

Beyond the noise, the real problem is that the demos must mirror the
Spring Boot baseline each *starter* was certified against — per its
README:

  > Spring Boot 3.3+ on Java 21+ (built/tested against 3.5)

easy-paging-spring-boot-starter has not (yet) published a release
certified against Spring Boot 4 / Spring Framework 7 / Jakarta EE 11.
Auto-bumping demos to SB4 would silently advertise an unverified
combination to anyone who clones a demo as a starting point.

This commit adds an `ignore` block that holds majors for:
  - org.springframework.boot:*  (the BOM driver)
  - io.spring.dependency-management
  - org.springframework:* and org.springframework.cloud:*
    (transitively pulled in; majors can land off the SB cadence)
  - gradle (wrapper) — each major needs hand verification of
    deprecations-now-errors before going green across 9 demos

Patch/minor bumps still flow through (and group correctly — PR #18
already proved that path), so security fixes within the 3.5.x line
land normally.

Lift these holds when each starter publishes its SB4-compatible
release line; the demos can then be upgraded together in one
intentional PR per starter, not piecemeal by a robot.

Follow-up:
  - Merge PR #18 (grouped patch/minor across 9 demos) and PRs
    #14-#17 (github-actions minors) since they're inside policy.
  - Close PRs #19-#36 (18 stragglers); the new policy guarantees
    they won't reappear on the next Dependabot run.
@jlc488 jlc488 merged commit 1c757a9 into main May 23, 2026
3 checks passed
@jlc488 jlc488 deleted the fix/dependabot-hold-major-bumps branch May 23, 2026 07:44
This was referenced May 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant