Release for every supported Jackson line

[k163377]

Problem

Jackson 2.x currently maintains two LTS lines, 2.21 and 2.22. This project is based on 2.21, so a release only ever covers that line.

Approach

The version scheme already encodes the Jackson version (<jackson version>-beta<N>), so the two lines never collide: 2.21.5-beta38 and 2.22.1-beta38 are distinct coordinates, and the shared beta number shows at a glance that they are built from identical source.

JitPack builds a git tag, so the tag itself has to carry the right Jackson version. On every published release, the workflow creates a commit on top of the released tag that rewrites only the jackson line of the version catalog, and tags it for the other line. No branch is maintained; the derived commit is reachable from its tag and its parent is the released tag, so it stays traceable.

main ──● 2.21.5-beta38   (published manually, as today)
        └──● 2.22.1-beta38   (derived automatically)

Per line, the job:

1. Resolves the latest patch of that line from Maven Central, and derives <latest patch>-<same beta number>.
2. Skips if that tag already exists. This covers the released tag itself, re-runs, and any recursion.
3. Checks out the released tag and rewrites gradle/libs.versions.toml.
4. Verifies that the resulting Gradle version equals the tag. JitPack resolves artifacts by tag name, so a mismatch would publish nothing usable.
5. Runs lint and test.
6. Commits, tags, pushes, creates the release, and builds it on JitPack.

The tag is pushed only after lint and test pass, so a line that is incompatible with the current source is simply not released. fail-fast: false keeps one line from taking the others down. In practice only the 2.22 job does work, since 2.21 skips on the existing tag.

Adding or dropping a line is a single edit to the matrix.

About the JACKSON_VERSION override

settings.gradle.kts gains a JACKSON_VERSION override, mirroring the existing KOTLIN_VERSION one. CI does not use it — the release path has to rewrite the catalog, because JitPack builds the tag content and no environment variable reaches it.

It is there so that a failure reported by this workflow can be reproduced locally with JACKSON_VERSION=2.22.1 ./gradlew test, without editing the catalog. Since there is no pre-release check, that reproduction path is the only thing standing between a red release run and hand-editing files. Drop it if that does not seem worth an unused-by-CI mechanism.

Verification

Confirmed locally:

Check	Result
./gradlew test against Jackson 2.22.1	BUILD SUCCESSFUL — the current source is compatible with both lines
Resolution under 2.22.1	jackson-databind 2.22.1, jackson-annotations 2.22 — correct, since annotations has no patch component and must come from the BOM
Plan step shell, run as written	2.21 -> 2.21.5-beta38 (skipped, tag exists), 2.22 -> 2.22.1-beta38
Rewrite step, run against the real catalog	Gradle version becomes 2.22.1-beta38 and matches the tag
JACKSON_VERSION=2.22.1 ./gradlew properties	2.22.1-beta38

The workflow itself has not run on GitHub yet. workflow_dispatch takes a tag, so it can be exercised against an existing release without cutting a new one.

Trade-off

There is no pre-release check against 2.22, so an incompatibility surfaces when the release runs rather than before. The 2.21 release is unaffected, but the decision of whether to fix 2.22 or skip it lands in the middle of the release.

🤖 Generated with Claude Code