Depends on #53.
#53 gives this repository a version and a tag. Nothing tells a reader what is
different between two of them. For a site that is going to be downloadable and
servable by somebody else, that is a real question rather than a formality: an
operator holding a bundle has to decide whether the next one is worth taking,
and a version number on its own does not answer it.
The repository whose gate this plan takes as its target publishes one. This one
does not:
gh api repos/Flowfin/jellyfin-plugin-sso/contents/CHANGELOG.md --jq '.name,.size'
CHANGELOG.md
17755
gh api repos/Flowfin/site/contents/CHANGELOG.md
gh: Not Found (HTTP 404)
Run 2026-08-08.
What belongs in it follows from what the version means, which #53 settles: the
version tracks the generator and the structure rather than the words. So a file
listing every corrected sentence would bury the entries that matter, and one
that never mentioned a page appearing would be useless. What gets an entry is
anything that changes what an operator serves or what a reader can reach. A page
added or removed. An address that moves, which is the entry a reader who linked
to a page needs most. A budget number that changes. A check that starts refusing
something it used to allow. Anything that changes the bytes the build produces
from unchanged input, since that is the claim #42 makes and a reader comparing
two bundles will notice first.
It is written by hand rather than generated. A file generated from commit
subjects is a second copy of the history that already exists, and what an
operator needs is the sentence saying whether this release moves something they
depend on, which a subject line does not say.
The release run is where this stops being a courtesy. #53 has the run build,
gate, attach the bundle and create the tag. It also refuses a tag whose version
has no section here, because a release nobody described is exactly the case this
file exists to prevent, and a file kept by intention drifts on the first busy
day.
Done when
CHANGELOG.md exists, states which kinds of change it records and which it
leaves out with the reason for the omission, carries a section for what is
unreleased and one per released version, and the release run in #53 fails when
the version being tagged has no section in it.
Depends on #53.
#53 gives this repository a version and a tag. Nothing tells a reader what is
different between two of them. For a site that is going to be downloadable and
servable by somebody else, that is a real question rather than a formality: an
operator holding a bundle has to decide whether the next one is worth taking,
and a version number on its own does not answer it.
The repository whose gate this plan takes as its target publishes one. This one
does not:
Run 2026-08-08.
What belongs in it follows from what the version means, which #53 settles: the
version tracks the generator and the structure rather than the words. So a file
listing every corrected sentence would bury the entries that matter, and one
that never mentioned a page appearing would be useless. What gets an entry is
anything that changes what an operator serves or what a reader can reach. A page
added or removed. An address that moves, which is the entry a reader who linked
to a page needs most. A budget number that changes. A check that starts refusing
something it used to allow. Anything that changes the bytes the build produces
from unchanged input, since that is the claim #42 makes and a reader comparing
two bundles will notice first.
It is written by hand rather than generated. A file generated from commit
subjects is a second copy of the history that already exists, and what an
operator needs is the sentence saying whether this release moves something they
depend on, which a subject line does not say.
The release run is where this stops being a courtesy. #53 has the run build,
gate, attach the bundle and create the tag. It also refuses a tag whose version
has no section here, because a release nobody described is exactly the case this
file exists to prevent, and a file kept by intention drifts on the first busy
day.
Done when
CHANGELOG.mdexists, states which kinds of change it records and which itleaves out with the reason for the omission, carries a section for what is
unreleased and one per released version, and the release run in #53 fails when
the version being tagged has no section in it.