docs(profile): replace hardcoded library versions with Maven Central badges#6
Merged
Merged
Conversation
Open-source section under `// open source` was carrying hardcoded version strings for three of the four library entries — same drift pattern that just bit on devslab-examples and forced PR #3 here days after ssrf-guard 3.1.0 shipped. Replaced with shields.io badges sourced from Maven Central so the next release auto-updates the profile. Mappings: ssrf-guard → kr.devslab/ssrf-guard (no prefix; single line) easy-paging-starter → kr.devslab/easy-paging-spring-boot-starter × 2 badges: versionPrefix=4 (SB4 active), versionPrefix=3 (SB3 maintenance) api-log → kr.devslab/api-log (no prefix; SB3 only) The two easy-paging badges keep the SB4 / SB3 lines visually distinct — without the versionPrefix filter, the SB3 badge would jump to the SB4 latest version the moment a 4.x.y patch ships, hiding the maintenance line's actual state. devslab-examples row has no version to badge (it's a demo repo, not published), so the only change there (already in main) was the demo count breakdown from #4. Note on `versionPrefix=3` / `=4`: aligned with the new Spring-major-versioning policy (.github/VERSIONING.md). The easy-paging renumber 0.4.0 → 3.0.0 and 0.5.0 → 4.0.0 has already shipped to Maven Central, so the badges will resolve correctly on first render.
Conflict resolution between this PR's badge replacement and #7's in-flight renumber prose update (0.5.0→4.0.0, 0.4.0→3.0.0, plus a new sentence pointing at VERSIONING.md and the renamed tree/3.x branch). Took both sides: - badge structure from the feature branch (this PR's whole point) - renumbered prose + versioning-policy callout from main (#7's whole point) Net effect on the easy-paging row: two badges (versionPrefix=4 for SB4, versionPrefix=3 for SB3) followed by the new "Library major matches Spring Boot major" sentence and the tree/3.x maintenance-branch link. The two pieces don't fight - one replaces hardcoded numbers with self-updating display, the other rewords the framing around the renumber. Neither would be complete without the other. ssrf-guard and api-log rows: no prose conflict (only the version display differed), kept the badge replacement as-is.
jlc488
added a commit
that referenced
this pull request
May 23, 2026
…tral coordinate) The api-log badge URL was pointing at `kr.devslab/api-log` — a coordinate that doesn't exist. api-log has been multi-module since 0.6.0; the published artifacts are `api-log-core`, `-jpa`, `-r2dbc`, `-mybatis`. The badge was rendering "no version found." Caught by an in-flight #8 (closed in favor of folding the fix into this branch, since both PRs touched the same line and #6 was the active badge-conversion branch). Changes: - badge URL: kr.devslab/api-log → kr.devslab/api-log-core - label: kr.devslab:api-log → kr.devslab:api-log-* (wildcard communicates "all four modules ship at one version") - link: central.sonatype.com/artifact/kr.devslab/api-log → ../api-log-core (the broken link was a side effect of the same root cause) - prose: added "all modules ship at the same version" to the module-split note, so readers don't wonder why the badge label has a `*` After the api-log 3.0.0 renumber publishes to Maven Central (api-log#2 merged, tag pending), the badge will resolve to 3.0.0 automatically. No further README edits needed for patch releases.
3 tasks
jlc488
added a commit
to devslab-kr/devslab-examples
that referenced
this pull request
May 23, 2026
…nded (#59) Deferred from the earlier badge PR (#56, closed) — that one used the pre-renumber prefixes (versionPrefix=0.4 / 0.5). After #57 landed the renumber (easy-paging 0.4.0→3.0.0, 0.5.0→4.0.0), this PR finishes the badge conversion with the correct post-renumber prefixes. Changes per language (2 files, 40 lines each): Section headers — align with the renumber: "Spring Boot 4 (`0.5.x` line)" → "(`4.x` line)" "Spring Boot 3 maintenance (`0.4.x` line)" → "(`3.x` line)" Korean equivalents. Maintenance branch link — the branch was renamed too: [`0.4.x` branch](.../tree/0.4.x) → [`3.x` branch](.../tree/3.x) Column header — slight tightening since the cell content is now a badge instead of a coordinate string: "Maven Central coordinates" → "Maven Central" 14 rows — each "Maven Central coordinates" cell: [`kr.devslab:<artifact>:<version>`](sonatype-link) → [](sonatype-link) Where N = 4 for SB4 rows, N = 3 for SB3 rows. ssrf-guard rows use no prefix (single-line library; whatever's latest on Maven Central is what readers should pull). The versionPrefix filter keeps the two easy-paging lines visually independent — without it, the SB3 row's badge would jump to the latest 4.x patch the moment one ships. Per-demo README "Files of interest" tables intentionally left as prose (copy-paste-friendly Gradle snippets; #55 already aligned them with the build files). A CI mismatch check is a follow-up if those drift again. Sibling PRs in the same badge sweep, already merged: - devslab-kr/.github#6 (org profile) - devslab-kr/api-log#3 (api-log doc surface for 3.0.0 renumber) Maven Central propagation note: api-log v3.0.0 published 13:44Z, profile badge picked it up within minutes — same auto-update behavior will apply to these demos on the next easy-paging patch release.
This was referenced May 23, 2026
jlc488
added a commit
that referenced
this pull request
May 23, 2026
Follow-up to #6 — matches the label-simplification pattern just applied to devslab-examples#59 (badge labels) and the easy-paging starter docs PR. User flagged that the long `label=kr.devslab:<artifact>` made the version text render small. Changes: - ssrf-guard badge: drop `?label=kr.devslab%3Assrf-guard` → default "Maven Central | 3.1.0" rendering - api-log-core badge: drop `?label=kr.devslab%3Aapi-log-*` → default "Maven Central | 3.0.0" rendering (api-log was renumbered 0.6.0 → 3.0.0; badge picked it up automatically — proving the auto- update value of the badge pattern) - easy-paging easy-paging dual badge: KEEPS the short labels `Spring Boot 4` / `SB3 maintenance`. Reason: that entry has TWO badges side-by-side on the same line — without a distinguishing label, readers can't tell which is the SB4 line and which is the SB3 maintenance line. The labels are short enough that the version text still renders at a readable size. Trade-off captured: the rule "default label" is broken for the dual-badge case in favor of "label that distinguishes the two side-by- side badges." Single-badge entries take the default; entries with ambiguity get a short discriminator. Both languages updated symmetrically.
jlc488
added a commit
that referenced
this pull request
May 23, 2026
…note (#10) The Maven Central badge target \`kr.devslab/api-log\` doesn't exist as a published artifact — api-log ships as four coordinates (\`api-log-core\`, \`-jpa\`, \`-r2dbc\`, \`-mybatis\`) since the 0.6.0 multi-module split. The badge has been rendering as "maven-central: not found" since the badges PR (#6). Repoint to \`kr.devslab/api-log-core\` — the core module every backend artifact depends on — so the badge actually displays the active version. All 4 api-log artifacts ship at the same version line, so api-log-core's badge is representative of the whole family. Now correctly displays "maven-central: v3.0.0" after the recent renumber. Also adds the same versioning-policy sentence already on ssrf-guard and easy-paging, for consistency.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The `// open source` section had hardcoded version strings for three library entries — same drift pattern that just forced #3 (ssrf-guard 3.0.1 → 3.1.0 manual bump days after release). Replaced with shields.io Maven Central badges so the next release auto-updates the profile.
(devslab-examples row had no version to badge — it's a demo repo, not published; only the demo count breakdown landed in #4.)
Why `versionPrefix` on easy-paging
Without the filter, the SB3 maintenance badge would jump to the SB4 latest version the moment a 4.x.y patch ships, hiding the maintenance line's actual state. With `versionPrefix=3` and `versionPrefix=4` each line shows its own latest patch independently — matches the dual-line model.
Alignment with the new VERSIONING.md
This PR uses `versionPrefix=3` / `versionPrefix=4` against the just-shipped Spring-major-aligned renumbers (easy-paging 0.4.0 → 3.0.0 / 0.5.0 → 4.0.0). If those renumbers hadn't shipped yet, the badges would render `Maven Central | no matching version` for the unreleased line — but per current state they should resolve immediately.
api-log isn't renumbered yet (still `0.6.x`); the no-prefix badge will show whatever's latest, and when the `0.6.0 → 3.0.0` renumber lands, the badge will auto-track without any edit to this profile.
Test plan