NotExpectedYet
ef3df2d939
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.
58 lines
2.4 KiB
Markdown
58 lines
2.4 KiB
Markdown
# Working in this repository
|
|
|
|
`master` releases itself. Every push runs `.gitea/workflows/release.yml`, which
|
|
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.
|
|
|
|
## Commit subjects are release input
|
|
|
|
The subject is both the version decision and the sentence a user reads in the
|
|
release notes. Write it for that reader:
|
|
|
|
- `feat: …` — the change adds a capability. Minor bump: `0.1.0` → `0.2.0`.
|
|
- `feat!: …` or `fix(x)!: …` — the change breaks an existing install. Major
|
|
bump: `0.1.0` → `1.0.0`, and the note lands under **Breaking**. `[major]`
|
|
anywhere in the subject does the same when a `!` will not fit.
|
|
- `fix: …`, `docs: …`, or a plain sentence — everything else. Patch bump:
|
|
`0.1.0` → `0.1.1`.
|
|
- `[skip release]` — this push publishes nothing.
|
|
|
|
`feat` has to be a word, so `Fix the feature flag leak` is a patch. Only the
|
|
subject line is read; the body is not.
|
|
|
|
## Commit as the work lands
|
|
|
|
Commit each step as soon as it is finished rather than leaving it in the tree
|
|
until the end. Two reasons, and the second is the one that bites:
|
|
|
|
- An uncommitted change has no release note at all. The subject is the sentence a
|
|
user reads, so work that never becomes a commit never becomes a sentence.
|
|
- A tree carrying four unrelated changes cannot be split into four honest
|
|
subjects after the fact — the reasoning behind each one is only in the
|
|
transcript by then, and the range picks its bump from whatever subjects it
|
|
ends up with. One `feat:` batched in with a handful of fixes is a minor bump
|
|
for all of them.
|
|
|
|
Keep a subject to one change and the version follows from it.
|
|
|
|
A commit here is local. Pushing to `master` is what releases, so it stays a
|
|
separate, deliberate step.
|
|
|
|
## The release job owns the version and the changelog
|
|
|
|
`package.json`'s `version` and `CHANGELOG.md` are the job's to write, derived
|
|
from the commits. Pushing to `master` is the whole trigger — the tag and the
|
|
release come with it.
|
|
|
|
## Checking before pushing
|
|
|
|
```sh
|
|
npm run release:plan # would this HEAD release? (yes/no)
|
|
npm run release:notes # the exact notes it would publish
|
|
npm run test:release # the checks behind the bump and the notes
|
|
```
|
|
|
|
The rules in full — the marker table, first-release behaviour, how prose commits
|
|
are handled — are in the README under *Releases*.
|