Skip to document
erudeon/ops
internaloperations/sops/releasing-a-version.md

SOP: Releasing a version

Owner
Bence
Updated
20 August 2026
Review
quarterly
History(1)SourceLast changed 20 August 2026 by Bence

This SOP is thin on purpose. The procedure lives in erudeon/passtheyear/docs/BRANCHING.md. This page says who does it, when, and what has to be true first. If you find yourself adding commands here, they belong in that document instead.

Purpose

Turn a set of merged changes into a named, deployable release.

Scope

Covers cutting a version and publishing its release notes. Does not cover putting it on the production box; that is deploying-to-production.md.

RACI

Step Responsible Accountable Consulted Informed
Decide a release is due Bence Bence
Version-bump pull request Bence Bence
Cut the tag Bence Bence

Steps

1. Decide the version

  • Who: Bence
  • When: when enough has merged to be worth naming, or a fix needs to reach production
  • How: semantic versioning. Anything labelled breaking makes it a major. The labels on the merged pull requests are what generate the release notes, so a mislabelled pull request produces wrong notes.
  • Output: a decided version number

2. Bump the version

  • Who: Bence
  • When: before any tag exists
  • How: its own pull request, changing version in the root package.json and nothing else. Never bump the version inside a feature branch.
  • Output: a merged commit carrying the new version

3. Cut the tag

  • Who: Bence
  • When: after the bump has merged and CI is green
  • How: see docs/BRANCHING.md. The tag only names the version that is already in package.json; tooling refuses a tag that disagrees with it.
  • Output: a v* tag, a published GitHub Release, and an image stamped with the version

Exceptions

Situation What to do
A fix must reach production immediately Hotfix path in docs/BRANCHING.md. Still gets a version; urgency does not mean unnamed
The break is JavaScript only, on the iOS app It can ship over the air. See the hotfix runbook in docs/OPERATIONS.md
CI is red on a required check Do not tag. main deploys to staging automatically, so a red main is already live somewhere
  • erudeon/passtheyear/docs/BRANCHING.md — the procedure
  • deploying-to-production.md — what happens next