feat: Add app release flow (Changesets) and API versioning policy - #180
Open
thekidnamedkd wants to merge 2 commits into
Open
feat: Add app release flow (Changesets) and API versioning policy#180thekidnamedkd wants to merge 2 commits into
thekidnamedkd wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
thekidnamedkd
changed the title
thekidnamedkd
changed the title
thekidnamedkd
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two independent versioning concerns, deliberately decoupled from the MCP npm flow (#179): a working app release flow and the API contract versioning policy.
App release flow (implemented)
Lightweight subset of the Aragon standard (Changesets + a signed Release PR), trimmed to opsec + low friction — no Slack/Linear/staging/e2e.
.github/workflows/release.yml(manual dispatch, prepare) — consumes pending changesets → bumps version +CHANGELOG.md, commits GPG-signed, opensrelease/vX.Y.Z → main..github/workflows/release-finalize.yml(on the release PR merging) — tagsvX.Y.Z+ cuts a GitHub Release from the CHANGELOG section. Needs no secrets..changeset/, config, seededpackage.jsonversion0.1.0).OP_SERVICE_ACCOUNT_TOKENstored in GitHub), GPG-signed release commit, SHA-pinned actions, read-only built-in token + scoped bot PAT for writes (so the Release PR fires CI).v*, disjoint frommcp-v*— the two release flows never cross-trigger.Content stays separate: this versions app code only. Content ships on otf-cms's own publish clock and is read at runtime — a content edit needs no app release, and an app release never reships content.
API versioning policy (docs)
docs/api-versioning.md—/api/v1is a manual, contract-major version: additive changes ship under v1, breaking changes cut/api/v2alongside. Not programmatic; recommends a CI contract-diff guard (detect, don't auto-bump). Four-clocks table so contract / data-provenance / app-release / MCP-package never couple.docs/app-releases.md— the flow above + DevOps handoff.DevOps handoff
OP_SERVICE_ACCOUNT_TOKEN(GitHub secret) + a 1Password vault withARABOT_PAT(contents+PR write) and the bot GPG key/passphrase. Details indocs/app-releases.md; confirm/repoint theop://kv_otf_infra/...paths inrelease.yml.Not built (intentional)
The app
release.ymlstaging/e2e ceremony,release-pr-cancel, rollback/hotfix, and the API contract-diff CI test — described as scope, deferred to follow-ups.