📣 easy-paging 3.0.0 + 4.0.0 — Spring-major-aligned versioning policy / Spring-major 정렬 버전 정책 도입

[jlc488]

English · 한국어

TL;DR

• easy-paging-spring-boot-starter renumbered: SB4 active line is now 4.0.0 (was 0.5.0); SB3 maintenance line is now 3.0.0 (was 0.4.0).
• The library's major version number now matches the Spring Boot major it targets — see the new org-wide versioning policy.
• No code, API, or dependency changes. Same Spring Boot 4 baseline on 4.x, same Spring Boot 3.3–3.5 baseline on 3.x. Published JAR bytes are identical to 0.5.0 / 0.4.0 apart from the version coordinate.
• All 8 easy-paging demos in this repo bumped to the new coordinates in lockstep.

What changed

Line	Was	Now
Spring Boot 4 active	0.5.0	4.0.0
Spring Boot 3.3–3.5 maintenance	0.4.0	3.0.0

- implementation("kr.devslab:easy-paging-spring-boot-starter:0.5.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter:4.0.0")
- implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:0.5.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:4.0.0")

Or for SB3:

- implementation("kr.devslab:easy-paging-spring-boot-starter:0.4.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter:3.0.0")
- implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:0.4.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:3.0.0")

Previous 0.4.0 / 0.5.0 artifacts remain on Maven Central as historical references — they don't disappear, they just stop receiving new releases. The next patch will be 3.0.1 (SB3) or 4.0.1 (SB4).

Why we did this

A few days after we shipped the 0.4.x (SB3) / 0.5.x (SB4) parallel-line setup, Dependabot opened devslab-examples PR #50 — bumping easy-paging 0.4.0 → 0.5.0 across the 4 SB3 demos. CI went red on all four, because 0.5.0 is the SB4 release line and those demos pin Spring Boot 3.5.

The cause: the starter was pre-1.0, so 0.4 → 0.5 reads as a minor bump to Dependabot — even though in this codebase it's the SB3 → SB4 release-line jump. The standard update-types: ["version-update:semver-major"] ignore rule didn't catch it. We patched the symptom with an explicit versions: [">= 0.5"] filter in devslab-examples/.github/dependabot.yml, but it was clearly a symptom of a deeper modeling problem.

The fix is to align the library's major number with the Spring Boot major it targets. After this renumber:

• Reader clarity. "I'm on Spring Boot 3 — which library version do I need?" answers itself: 3.x.y.
• Dependabot correctness. The standard semver-major ignore now does exactly the right thing — 3.x stays on 3.x, future 4.x → 5.x is held as a major bump.
• Release-line longevity is obvious. When SB3 hits commercial-support-only mode, our 3.x line follows it. The contract reads off the version number.

The same policy applies to every kr.devslab library going forward. ssrf-guard was already at 3.x and is naturally aligned; api-log will renumber when it next ships.

What does NOT change

• ✅ Public APIs (@AutoPaginate, @KeysetPaginate, PageResponse<T>, KeysetPage<T>, R2dbcOffsetPagingSupport, ...) — unchanged
• ✅ Behaviour, configuration keys, auto-configuration shape — unchanged
• ✅ Transitive dependencies — same Spring Boot BOM, same MyBatis / PageHelper / Spring Data Commons versions on each line
• ✅ Documentation site URL (easy-paging.devslab.kr) — unchanged
• ✅ Module IDs (easy-paging-spring-boot-starter / -reactive) — unchanged
• ✅ Reactive companion artifact still ships on the same wire shape

The published 4.0.0 JAR is byte-identical to 0.5.0 apart from the <version> in the POM. Same for 3.0.0 vs 0.4.0.

Branch rename

The 0.4.x maintenance branch is renamed to 3.x to match. GitHub's branch rename API re-targets all open PRs and branch protection rules automatically — local clones with the old branch checked out can update with:

git fetch origin
git branch -m 0.4.x 3.x
git branch -u origin/3.x 3.x

The main branch (SB4 line) is untouched.

Updated demos

All 8 demos in this repo bumped to the new coordinates:

Spring Boot	Demos	Coordinate
SB4	easy-paging-sb4-demo, -sb4-keyset-demo, -sb4-postgres-demo, -sb4-reactive-demo	4.0.0
SB3 maintenance	easy-paging-demo, -keyset-demo, -postgres-demo, -reactive-demo	3.0.0

The .github/dependabot.yml versions: [">= 0.5"] filter from #54 was also removed — now that majors are aligned, the standard semver-major ignore does the right thing without explicit version pins.

Links

• 📦 Maven Central: easy-paging-spring-boot-starter · -reactive
• 🔧 Starter repo: main (SB4) · 3.x (SB3 maintenance)
• 📖 Documentation: easy-paging.devslab.kr
• 📜 Versioning policy: devslab-kr/.github/.github/VERSIONING.md
• 🔄 Previous release announcement (0.5.0): Discussion #51

---

한국어

요약

• easy-paging-spring-boot-starter 재번호링: SB4 active 라인 이제 4.0.0 (이전 0.5.0); SB3 maintenance 라인 이제 3.0.0 (이전 0.4.0).
• 라이브러리 메이저 숫자가 이제 타겟 Spring Boot 메이저와 일치 — 새 org 전체 버전 정책 참조.
• 코드 / API / 의존성 변경 전혀 없음. 4.x는 동일한 Spring Boot 4 베이스라인, 3.x는 동일한 Spring Boot 3.3–3.5 베이스라인. 발행된 JAR 바이트는 0.5.0 / 0.4.0과 동일 (POM의 버전 좌표만 다름).
• 이 repo의 8개 easy-paging 데모 모두 새 좌표로 동시 bump.

무엇이 바뀌나

라인	이전	지금
Spring Boot 4 active	0.5.0	4.0.0
Spring Boot 3.3–3.5 maintenance	0.4.0	3.0.0

- implementation("kr.devslab:easy-paging-spring-boot-starter:0.5.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter:4.0.0")
- implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:0.5.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:4.0.0")

SB3는:

- implementation("kr.devslab:easy-paging-spring-boot-starter:0.4.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter:3.0.0")
- implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:0.4.0")
+ implementation("kr.devslab:easy-paging-spring-boot-starter-reactive:3.0.0")

기존 0.4.0 / 0.5.0 아티팩트는 Maven Central에 historical reference로 잔존 — 사라지지 않고, 신규 릴리즈만 받지 않습니다. 다음 패치는 3.0.1 (SB3) 또는 4.0.1 (SB4).

왜 이렇게 했나

0.4.x (SB3) / 0.5.x (SB4) 병행 라인 셋업을 출시한 며칠 뒤, Dependabot이 devslab-examples PR #50을 열었습니다 — 4개 SB3 데모에서 easy-paging 0.4.0 → 0.5.0 bump. CI가 4개 다 red. 그 이유: 0.5.0은 SB4 라인이고 데모들은 Spring Boot 3.5에 pin되어 있어서.

근본 원인: 스타터가 pre-1.0이라 Dependabot이 0.4 → 0.5를 minor bump로 읽음 — 우리 코드베이스에선 SB3 → SB4 라인 점프인데도. 표준 update-types: ["version-update:semver-major"] ignore가 안 잡힘. devslab-examples/.github/dependabot.yml에 명시적 versions: [">= 0.5"] 필터로 증상 패치했지만, 더 깊은 모델링 문제의 징후.

해결: 라이브러리 메이저를 타겟 Spring Boot 메이저와 정렬. 이 재번호링 이후:

• 읽는 사람 명확성. "Spring Boot 3 쓰는데 어느 버전?" 자명: 3.x.y.
• Dependabot 정확성. 표준 semver-major ignore가 정확히 옳은 일 — 3.x는 3.x에 머물고, 미래 4.x → 5.x는 메이저 bump로 차단.
• 릴리즈 라인 수명 명백. SB3가 commercial-support-only로 진입하면 우리 3.x도 따라감. 계약이 버전 숫자에 박혀있음.

같은 정책이 향후 모든 kr.devslab 라이브러리에 적용. ssrf-guard는 이미 3.x라 자연 정렬됨; api-log는 다음 릴리즈 때 재번호링 예정.

무엇이 안 바뀌나

• ✅ Public API (@AutoPaginate, @KeysetPaginate, PageResponse<T>, KeysetPage<T>, R2dbcOffsetPagingSupport, ...) — 그대로
• ✅ 동작 / 설정 키 / 자동 설정 형태 — 그대로
• ✅ Transitive 의존성 — 각 라인의 Spring Boot BOM, MyBatis / PageHelper / Spring Data Commons 동일
• ✅ 문서 사이트 URL (easy-paging.devslab.kr) — 그대로
• ✅ 모듈 ID (easy-paging-spring-boot-starter / -reactive) — 그대로
• ✅ Reactive 자매 아티팩트는 같은 wire shape로 계속

발행된 4.0.0 JAR는 POM의 <version> 외에는 0.5.0과 byte-identical. 3.0.0 vs 0.4.0도 마찬가지.

브랜치 rename

0.4.x maintenance 브랜치를 **3.x**로 rename해서 매칭. GitHub의 브랜치 rename API가 모든 open PR과 브랜치 보호 규칙을 자동 retarget — 옛 브랜치를 로컬에 checkout 중인 경우 다음으로 업데이트 가능:

git fetch origin
git branch -m 0.4.x 3.x
git branch -u origin/3.x 3.x

main 브랜치 (SB4 라인) 는 그대로.

업데이트된 데모

이 repo의 8개 데모 모두 새 좌표로 bump:

Spring Boot	데모	좌표
SB4	easy-paging-sb4-demo, -sb4-keyset-demo, -sb4-postgres-demo, -sb4-reactive-demo	4.0.0
SB3 maintenance	easy-paging-demo, -keyset-demo, -postgres-demo, -reactive-demo	3.0.0

.github/dependabot.yml의 versions: [">= 0.5"] 필터 (PR #54)도 제거 — 메이저가 정렬됐으니 표준 semver-major ignore만으로 충분.

링크

• 📦 Maven Central: easy-paging-spring-boot-starter · -reactive
• 🔧 스타터 repo: main (SB4) · 3.x (SB3 maintenance)
• 📖 문서: easy-paging.devslab.kr
• 📜 버전 정책: devslab-kr/.github/.github/VERSIONING.md
• 🔄 이전 릴리즈 발표 (0.5.0): Discussion #51