The subjects are the release notes, so a working tree is a queue of unwritten
sentences: a change left uncommitted until the end is a change with no note, and
a batch of unrelated changes cannot be split into honest subjects once the
reasoning behind each one is only in the transcript.
The second reason is the one that changes a version, so it is stated too: the
range picks its bump from whatever subjects it ends up with, and one `feat:`
batched in with a handful of fixes is a minor bump for all of them.
Also says outright that committing is local, because pushing to `master` is what
releases and that is a different decision.
A plugin installed as a bare git+https URL is pinned to a commit, so with no
tags there is nothing for `dsh plugin update` to move to. The workflow reads
the commit subjects since the last tag, bumps package.json, prepends
CHANGELOG.md, tags vX.Y.Z, and publishes the Gitea release with those subjects
as the body. The decision logic lives in .gitea/scripts/release.sh so it runs
and is tested without a runner (`npm run test:release`).
NotExpectedYet