Lock the release version to the platform's, not an independent counter #44

Merged

geusebio merged 1 commit from feature/version-lockstep-with-app into main

2026-08-25 17:44:23 +00:00

geusebio commented

2026-08-25 17:39:19 +00:00

Owner

What

Changes release-cadence.yml (and its by-hand equivalent, cut-release.sh)
so the version tagged here is read from the platform repo
(Grey.ooo/someones.computer) instead of computed by bumping this repo's
own previous tag.

Why

Follow-up to #43: someones.computer is one product with two shipped
artifacts, the web app and this CLI, and per discussion they should carry
one version between them rather than two independently-incrementing
counters. The platform is currently at v0.1.15; this repo had just been
bumped to v0.1.1 under the old scheme.

How it decides what to tag

git ls-remote --tags against Grey.ooo/someones.computer for its newest
v* (both repos are public, so this needs no cross-repo token).
If this repo is already at that version, nothing to do.
Otherwise: same guards as before (previous tag actually has a Forgejo
release, the target commit is CI-green, forward-only through this
repo's own commit history) plus a new one — the platform's version must
sort newer than this repo's previous tag, or the two have desynced and
it errors instead of guessing.
The bump: patch|minor workflow_dispatch input is gone; there's nothing
left for it to mean.

A platform-only release cycle still produces a tag here, pointing at
whatever agent commit was already current, even with no CLI change behind
it — intentional, so sc --version and the app's own version never
disagree about what "someones.computer vX.Y.Z" means.

v0.1.1

Cut by hand in #43 before this decision was made. Left in place rather
than deleted/rewritten — it's superseded, not wrong, and rewriting
published tag history is worse than an orphaned patch release sitting
under a much larger platform-locked number from here on.

Verified

actionlint and shellcheck clean. Not run live (would cut a real
release) — same reasoning as #43: the logic is adapted from a pattern
already proven in the platform repo's own release-cadence.yml, with one
new piece (the cross-repo ls-remote) that's a plain read, not a mutation.

## What Changes release-cadence.yml (and its by-hand equivalent, cut-release.sh) so the version tagged here is read from the platform repo (Grey.ooo/someones.computer) instead of computed by bumping this repo's own previous tag. ## Why Follow-up to #43: someones.computer is one product with two shipped artifacts, the web app and this CLI, and per discussion they should carry one version between them rather than two independently-incrementing counters. The platform is currently at v0.1.15; this repo had just been bumped to v0.1.1 under the old scheme. ## How it decides what to tag - `git ls-remote --tags` against Grey.ooo/someones.computer for its newest `v*` (both repos are public, so this needs no cross-repo token). - If this repo is already at that version, nothing to do. - Otherwise: same guards as before (previous tag actually has a Forgejo release, the target commit is CI-green, forward-only through this repo's own commit history) plus a new one — the platform's version must sort newer than this repo's previous tag, or the two have desynced and it errors instead of guessing. - The `bump: patch|minor` workflow_dispatch input is gone; there's nothing left for it to mean. **A platform-only release cycle still produces a tag here**, pointing at whatever agent commit was already current, even with no CLI change behind it — intentional, so `sc --version` and the app's own version never disagree about what "someones.computer vX.Y.Z" means. ## v0.1.1 Cut by hand in #43 before this decision was made. Left in place rather than deleted/rewritten — it's superseded, not wrong, and rewriting published tag history is worse than an orphaned patch release sitting under a much larger platform-locked number from here on. ## Verified `actionlint` and `shellcheck` clean. Not run live (would cut a real release) — same reasoning as #43: the logic is adapted from a pattern already proven in the platform repo's own release-cadence.yml, with one new piece (the cross-repo ls-remote) that's a plain read, not a mutation.

geusebio added 1 commit

2026-08-25 17:39:19 +00:00

Lock the release version to the platform's, not an independent counter

CI / build (pull_request) Successful in 45s

Details

46bff9fa0e

someones.computer is one product with two shipped artifacts, and they
should carry one version between them. release-cadence.yml now reads
the newest v* tag off Grey.ooo/someones.computer and tags this repo's
current main at that number, instead of bumping its own previous tag
by patch/minor — dropping the now-meaningless bump input along with
it. cut-release.sh and the README follow the same change.

v0.1.1, cut here by hand before this decision, is superseded rather
than removed — the next cut jumps straight to whatever the platform
is on, same as any platform-only release cycle will from here on.

geusebio changed title from ~~WIP: Lock the release version to the platform's, not an independent counter~~ to Lock the release version to the platform's, not an independent counter

2026-08-25 17:43:15 +00:00

geusebio merged commit 699882631c into main

2026-08-25 17:44:23 +00:00

geusebio deleted branch feature/version-lockstep-with-app

2026-08-25 17:44:23 +00:00

geusebio referenced this pull request from a commit

2026-08-25 17:44:25 +00:00

Lock the release version to the platform's, not an independent counter (#44)