This is for maintainers. RELEASING.md in the repository has every detail and the reasons behind each step.
How versions work
kb4it/VERSIONnames the release being prepared, for example0.8.0. Onlyscripts/release.shchanges it.- KB4IT follows Semantic Versioning. While the major number is 0, a change that breaks sites or themes raises the minor number.
- A build from a clone adds
git describetokb4it --version, so development builds need no extra numbering.
Steps
-
See what would happen; this writes nothing:
bash scripts/release.sh --dry-run -
Prepare: set the version, date the changelog and draft the notes:
bash scripts/release.sh -
Edit
releases/X.Y.Z.mdfor someone deciding whether to update: one sentence, then the changes they would notice. Delete theTODOline. -
Check and commit. This runs the tests, the theme check and the wheel check, and commits
chore(release): X.Y.Zonly if all pass:bash scripts/release.sh --commit -
Open a pull request to
master, let CI pass and merge it. Then tag the merge commit:bash git checkout master && git pull --ff-only git tag vX.Y.Z && git push origin vX.Y.Z -
The tag starts
.github/workflows/publish.yml. It checks that the tag, the version files, the changelog and the notes agree, runs the tests and the theme check, publishes to PyPI and creates the GitHub release. -
Install the new version from PyPI to check it, then open the next cycle:
bash scripts/release.sh --open 0.9.0
Themes declare the KB4IT they need
When a theme starts using something new from the core, raise the kb4it requirement in its theme.json in the same change. The theme check refuses a release whose themes need a newer KB4IT.