[SubMob/ParserMob#269] Publish releases from develop on every merge

[mustafaozhan]

Closes #269

CCC consumes this library as a moving -SNAPSHOT off develop, so every merge here lands directly in CCC's dependency graph — no PR, no review, no CI gate in CCC, no trace in CCC's history. The last real release on Maven Central was 2022; master has been dormant since.

This makes develop the release branch: every merge publishes an immutable, signed X.Y.Z to Maven Central. CCC then pins real versions, Renovate opens a normal PR per release, and CCC's full pipeline runs on it — so a breaking change shows up as a red PR instead of landing silently.

Changes

File	Change
ProjectSettings.kt	isMaster() → isReleaseBranch(), matching develop. VERSION_DIF 27 → 335.
ParserMob.gradle.kts	New printVersion task so CI can read the resolved version.
main.yml	master dropped from triggers; job gets contents: write; new steps resolve the version and cut the GitHub release.
publish.yml	Deleted — see below.

Versioning stays fully automatic (x.y.<first-parent commit count>); there is still no manual bumping. The first release off this change is 2.0.0, and every merge after it increments.

publish.yml listened for v* tags, but tags pushed with GITHUB_TOKEN never trigger workflows, so it could not fire on an automated release. It also passed a secret named GITHUB_TOKEN to the reusable workflow, which GitHub reserves and rejects — CCC and AdTrack pass REPO_TOKEN instead.

The action it wrapped — marvinpinto/action-automatic-releases@v1.2.1, the same one CCC releases with — now runs directly as a step in main.yml. automatic_release_tag is set from the resolved Gradle version, which is what lets it run off a branch push: with no tag ref the action has nothing to cut.

Feature branches keep building as X.Y-SNAPSHOT and never publish.

Verified

./gradlew -q printVersion on this branch prints VERSION_NAME=2.0-SNAPSHOT; with GITHUB_REF_NAME=develop it takes the release path and computes from the commit count. Merge style here is squash, so the count advances by one per merge.

Why not promote develop → master

main.yml triggers on pushes to both branches, so promoting on every merge would re-run the whole 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.

Trade-off

Maven Central releases are immutable — a bad merge burns that version permanently. It can be superseded, not withdrawn.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.31%. Comparing base (c3a1615) to head (f68acb2).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #270   +/-   ##
========================================
  Coverage    79.31%   79.31%           
========================================
  Files            5        5           
  Lines          145      145           
  Branches        34       34           
========================================
  Hits           115      115           
  Misses          20       20           
  Partials        10       10           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.