Skip to content

chore(git): release process - #294

Open
sabinem wants to merge 4 commits into
developfrom
chore/release-process
Open

chore(git): release process#294
sabinem wants to merge 4 commits into
developfrom
chore/release-process

Conversation

@sabinem

@sabinem sabinem commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

This PR provides:

  • changelog

  • the release process written down

  • CHANGELOG.md: Keep a Changelog, hand-maintained, entry written in the PR that makes the change. [0.8.0] summarises what's in production today.

  • just version::bump: rolls [Unreleased] into a dated heading for the version being cut, so release notes can't be forgotten on release day.

  • RELEASING.md: that merges reach the running app; how to check what an instance serves (footer, or digest comparison); how to deploy deliberately; how to pin or roll back to an immutable - tag; the three version numbers; how to cut a release and make it deployable.

  • README.md / CLAUDE.md: pointers, plus a new invariant for the deploy-on-restart behaviour.

@sabinem
sabinem force-pushed the chore/release-process branch from 71b77db to 622b35b Compare September 9, 2026 11:38
@sabinem
sabinem changed the base branch from main to develop September 9, 2026 11:39
The repo had no changelog, so the only account of what a release
contains was the commit messages.

Keep a Changelog format, hand-maintained, one line per PR. The 0.8.0
entry summarises what is in production rather than reconstructing it
commit by commit; it predates the file and says so.

Deliberately not generated from commit messages.
@sabinem
sabinem force-pushed the chore/release-process branch from 622b35b to 1c0b0c0 Compare September 9, 2026 12:44
A hand-maintained changelog rots the moment someone forgets to move
[Unreleased] on release day. bump now lifts whatever sits under that
heading into a dated heading for the version being cut, and leaves
[Unreleased] empty again — so a version's notes are exactly what was
written while it was being built.
Nothing recorded how a change reaches the running app, and the
answer is not the obvious one. Every push to main republishes
temporary/*:latest, and an instance running that tag with
imagePullPolicy: Always picks it up on any container restart — an
eviction or an OOM kill deploys exactly as a rollout restart does.
So a merge to main is closer to a deploy than to a checkpoint, and
that was written down nowhere.

RELEASING.md says so plainly, then covers what follows from it: how
to see what an instance is actually serving, how to deploy
deliberately, and how to pin one to an immutable <version>-<commit>
tag so it stops moving before a demo.

It also corrects a belief worth naming: Chart.yaml's appVersion
holds back only a deployment that takes the chart's default tag. An
instance overridden to a moving tag reads none of it.
EOF
@sabinem
sabinem marked this pull request as draft September 10, 2026 06:54
@sabinem
sabinem marked this pull request as ready for review September 10, 2026 10:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant