[SubMob/LogMob#303] Publish releases from develop on every merge

[mustafaozhan]

Closes #303

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 104 → 533.
LogMob.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 3.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=3.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.