📣 api-log 3.0.0 — Spring-major-aligned versioning policy (renumber of 0.6.0) / 정책 정렬 재번호링

[jlc488]

English · 한국어

TL;DR

• api-log renumbered from 0.6.0 to 3.0.0 across all 4 modules (-core, -jpa, -r2dbc, -mybatis).
• The library's major version now matches the Spring Boot major it targets — see the org-wide versioning policy. api-log targets Spring Boot 3, so it ships on 3.x.y going forward.
• No code, API, or dependency changes. Same Spring Boot 3 baseline, same ApiLogWriter SPI, same auto-configuration. Published JAR bytes are identical to 0.6.0 apart from the version coordinate.
• This closes the renumber wave for the three kr.devslab libraries that needed alignment (ssrf-guard was already at 3.x and naturally aligned).

What changed

Artifact	Was	Now
kr.devslab:api-log-core	0.6.0	3.0.0
kr.devslab:api-log-jpa	0.6.0	3.0.0
kr.devslab:api-log-r2dbc	0.6.0	3.0.0
kr.devslab:api-log-mybatis	0.6.0	3.0.0

- implementation("kr.devslab:api-log-jpa:0.6.0")
+ implementation("kr.devslab:api-log-jpa:3.0.0")
- implementation("kr.devslab:api-log-r2dbc:0.6.0")
+ implementation("kr.devslab:api-log-r2dbc:3.0.0")
- implementation("kr.devslab:api-log-mybatis:0.6.0")
+ implementation("kr.devslab:api-log-mybatis:3.0.0")

(api-log-core comes transitively with whichever backend you pick.)

Previous 0.6.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.

Why we did this

A few days back, Dependabot opened devslab-examples PR #50 — bumping easy-paging 0.4.0 → 0.5.0 across the SB3 demos. CI went red on all four because 0.5.0 was the SB4 release line. The pre-1.0 versioning made the Spring-major jump invisible to Dependabot's semver-major ignore.

The org-wide fix: align the library major number with the Spring Boot major it targets. After this renumber wave:

• ssrf-guard 3.x.y — SB3 (already aligned)
• easy-paging 3.x.y (SB3 maint) · 4.x.y (SB4 active) — renumbered from 0.4.x / 0.5.x (Discussion #58)
• api-log 3.x.y — SB3, renumbered from 0.6.0 (this announcement)

Concrete benefits:

1. Reader clarity — "I'm on Spring Boot 3, which version?" answers itself: 3.x.y.
2. Dependabot correctness — the standard semver-major ignore now does the right thing; no special versions: [">= X"] filters needed in consumer projects.
3. Release-line longevity is obvious — when Spring Boot 3 hits commercial-support-only mode, our 3.x follows it.

What does NOT change

• ✅ Public APIs (ApiLogWriter SPI, ApiLogProperties, all @AutoConfiguration beans) — byte-identical
• ✅ Behaviour (event pipeline, async listener, schema initializer per backend) — identical
• ✅ Dependencies — same Spring Boot 3.5.x baseline, same transitives per backend
• ✅ Module IDs (api-log-core, api-log-jpa, api-log-r2dbc, api-log-mybatis) — unchanged
• ✅ Documentation site URL (api-log.devslab.kr) — unchanged
• ✅ Database schema produced by each backend — unchanged

The published 3.0.0 JARs are byte-identical to 0.6.0 apart from the <version> coordinate in the POM.

Links

• 📦 Maven Central: api-log-core · -jpa · -r2dbc · -mybatis
• 🔧 Repo: devslab-kr/api-log
• 📖 Documentation: api-log.devslab.kr
• 📜 Versioning policy: devslab-kr/.github/.github/VERSIONING.md
• 🔄 Sibling release announcements: ssrf-guard 3.1.0 · easy-paging 3.0.0 + 4.0.0

---

한국어

요약

• api-log 재번호링 — 0.6.0 → 3.0.0, 4개 모듈 모두 (-core, -jpa, -r2dbc, -mybatis).
• 라이브러리 메이저가 이제 타겟 Spring Boot 메이저와 일치 — org 전체 버전 정책 참조. api-log는 Spring Boot 3 대상이라 3.x.y 라인으로 진행.
• 코드 / API / 의존성 변경 전혀 없음. 동일한 Spring Boot 3 베이스라인, 동일한 ApiLogWriter SPI, 동일한 자동 설정. 발행된 JAR 바이트는 0.6.0과 동일 (POM의 버전 좌표만 다름).
• 이로써 정렬이 필요했던 3개 kr.devslab 라이브러리 (ssrf-guard는 이미 3.x라 자연 정렬) 재번호링 wave 종료.

무엇이 바뀌나

아티팩트	이전	지금
kr.devslab:api-log-core	0.6.0	3.0.0
kr.devslab:api-log-jpa	0.6.0	3.0.0
kr.devslab:api-log-r2dbc	0.6.0	3.0.0
kr.devslab:api-log-mybatis	0.6.0	3.0.0

- implementation("kr.devslab:api-log-jpa:0.6.0")
+ implementation("kr.devslab:api-log-jpa:3.0.0")
- implementation("kr.devslab:api-log-r2dbc:0.6.0")
+ implementation("kr.devslab:api-log-r2dbc:3.0.0")
- implementation("kr.devslab:api-log-mybatis:0.6.0")
+ implementation("kr.devslab:api-log-mybatis:3.0.0")

(api-log-core는 backend 중 어느 것을 선택해도 transitive로 따라옵니다.)

기존 0.6.0 아티팩트는 historical reference로 Maven Central에 잔존 — 사라지지 않고, 신규 릴리즈만 받지 않습니다. 다음 패치는 3.0.1.

왜 이렇게 했나

며칠 전 Dependabot이 devslab-examples PR #50을 열었습니다 — SB3 데모에서 easy-paging 0.4.0 → 0.5.0 bump. CI 4개 다 red. 이유: 0.5.0은 SB4 라인. pre-1.0 버전이라 Spring-major 점프가 Dependabot의 semver-major ignore에 invisible.

org 전체 해법: 라이브러리 메이저를 타겟 Spring Boot 메이저와 정렬. 이 재번호링 wave 이후:

• ssrf-guard 3.x.y — SB3 (이미 정렬)
• easy-paging 3.x.y (SB3 maint) · 4.x.y (SB4 active) — 0.4.x / 0.5.x에서 재번호링 (Discussion #58)
• api-log 3.x.y — SB3, 0.6.0에서 재번호링 (이 발표)

구체적 이점:

1. 읽는 사람 명확성 — "Spring Boot 3 쓰는데 어느 버전?" 자명: 3.x.y.
2. Dependabot 정확성 — 표준 semver-major ignore가 정확히 옳은 일. consumer 프로젝트에 특수 versions: [">= X"] 필터 불필요.
3. 릴리즈 라인 수명 명백 — Spring Boot 3이 commercial-support-only로 진입하면 우리 3.x도 따라감.

무엇이 안 바뀌나

• ✅ Public API (ApiLogWriter SPI, ApiLogProperties, 모든 @AutoConfiguration 빈) — byte-identical
• ✅ 동작 (이벤트 파이프라인, async listener, backend별 schema initializer) — 동일
• ✅ 의존성 — 동일한 Spring Boot 3.5.x 베이스라인, backend별 동일한 transitives
• ✅ 모듈 ID (api-log-core, api-log-jpa, api-log-r2dbc, api-log-mybatis) — 그대로
• ✅ 문서 사이트 URL (api-log.devslab.kr) — 그대로
• ✅ 각 backend가 생성하는 DB 스키마 — 그대로

발행된 3.0.0 JAR는 POM의 <version> 외에는 0.6.0과 byte-identical.

링크

• 📦 Maven Central: api-log-core · -jpa · -r2dbc · -mybatis
• 🔧 Repo: devslab-kr/api-log
• 📖 문서: api-log.devslab.kr
• 📜 버전 정책: devslab-kr/.github/.github/VERSIONING.md
• 🔄 자매 릴리즈 발표: ssrf-guard 3.1.0 · easy-paging 3.0.0 + 4.0.0