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 exampleX.Y.Z. 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:
scripts/release.sh --dry-run -
Prepare: set the version, date the changelog and draft the notes:
scripts/release.sh -
If a bundled theme started using new core features since the last release, raise its
kb4itrequirement intheme.jsonto the new version now, and commit only those files. It cannot be done earlier, because the version files still name the previous release until step 2.RELEASING.mdhas the commands. -
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:scripts/release.sh --commit -
Open a pull request to
master, let CI pass and merge it. Then tag the merge commit: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, and publishes to PyPI. From the same wheel it pushes the container imageghcr.io/t00m/kb4it(amd64 and arm64) and builds the.deband.rpm. When all of that succeeded it creates the GitHub release with the packages attached. If a job fails for a transient reason, use Re-run failed jobs on that run; if the cause is in the tagged code, fix it and release the next patch version. Never move a tag. -
Install the new version from PyPI to check it, then open the next cycle:
scripts/release.sh --open X.Y.Z
Once, after the first release with an image
New packages on GitHub are private. Open your profile, Packages, kb4it, Package settings, and change the visibility to Public, so everyone can pull the image. RELEASING.md has the details.
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.