CCC consumes this library as a moving -SNAPSHOT off develop, so every merge here lands straight in CCC's dependency graph — no PR, no review, no CI gate in CCC, and no trace in CCC's history. When a change breaks CCC there is nothing to catch it.
The last real release on Maven Central was made in 2022; master has been dormant since.
Change
Make develop the release branch so every merge publishes an immutable X.Y.Z to Maven Central.
ProjectSettings.kt — isMaster() becomes isReleaseBranch() matching develop; VERSION_DIF recalibrated against develop's first-parent commit count. Versions stay fully automatic (x.y.<commit-count>), no manual bumping.main.yml — master dropped from triggers; the publish step now always produces a signed release.- A
printVersion task plus a gh release create step so the GitHub release is cut automatically.
publish.yml deleted — it listened for v* tags, but tags pushed with GITHUB_TOKEN never trigger workflows, so it could not fire.
Feature branches keep building as X.Y-SNAPSHOT and never publish.
Why this over keeping master
main.yml triggers on pushes to both branches, so promoting develop → master on every merge would re-run the entire CI on master for no added signal, and fast-forward promotion races when two PRs land close together. With a release per merge, master carries nothing develop doesn't.
Once this is in, CCC pins real versions instead of the snapshot. Renovate then opens a normal PR in CCC for each release, CCC's full pipeline runs on it, and a breaking change shows up as a red PR instead of silently landing.
Trade-off accepted: Maven Central releases are immutable, so a bad merge burns that version permanently — it can be superseded, not withdrawn.
CCC consumes this library as a moving
-SNAPSHOToffdevelop, so every merge here lands straight in CCC's dependency graph — no PR, no review, no CI gate in CCC, and no trace in CCC's history. When a change breaks CCC there is nothing to catch it.The last real release on Maven Central was made in 2022;
masterhas been dormant since.Change
Make
developthe release branch so every merge publishes an immutableX.Y.Zto Maven Central.ProjectSettings.kt—isMaster()becomesisReleaseBranch()matchingdevelop;VERSION_DIFrecalibrated against develop's first-parent commit count. Versions stay fully automatic (x.y.<commit-count>), no manual bumping.main.yml—masterdropped from triggers; the publish step now always produces a signed release.printVersiontask plus agh release createstep so the GitHub release is cut automatically.publish.ymldeleted — it listened forv*tags, but tags pushed withGITHUB_TOKENnever trigger workflows, so it could not fire.Feature branches keep building as
X.Y-SNAPSHOTand never publish.Why this over keeping master
main.ymltriggers on pushes to both branches, so promoting develop → master on every merge would re-run the entire CI on master for no added signal, and fast-forward promotion races when two PRs land close together. With a release per merge,mastercarries nothingdevelopdoesn't.Once this is in, CCC pins real versions instead of the snapshot. Renovate then opens a normal PR in CCC for each release, CCC's full pipeline runs on it, and a breaking change shows up as a red PR instead of silently landing.
Trade-off accepted: Maven Central releases are immutable, so a bad merge burns that version permanently — it can be superseded, not withdrawn.