Releases

Releases are annotated tags on main. There is no stable branch, no backports and no release candidates: the upgrade test is the gate, and bin/nibble-upgrade resolves the newest tag itself.

bin/nibble-release 0.6.0 --feed ../nibble_site/content/docs/releases.json

It refuses a malformed or backwards version, a dirty tree, and an empty Unreleased section. Then it bumps Nibble::VERSION, dates the changelog section, runs bin/ci, and only then commits and tags. Push with git push origin main --follow-tags.

--feed writes the release feed once the tag exists. It is optional, and the path belongs to another repository, so committing it there is yours to do.

The changelog is the release

CHANGELOG.md records what changed for a site running Nibble, under What's new, Changed, What's fixed and Security. Anything needing action carries an **Upgrade:** line. A release whose migrations cannot be undone says so, because the snapshot is then the only way back.

The feed a control panel reads is content/docs/releases.json in this site, generated from the whole changelog and capped at the most recent 25 releases. It is thrown away and rebuilt each time, so the changelog is the only record and the feed cannot disagree with it — editing an entry after its release still reaches every site.

Versions

Nibble::VERSION orders releases for people. The contracts — SCHEMA_FORMAT, THEME_API_VERSION, CONTENT_FORMAT_VERSION — are what code checks. Release::MINIMUM_UPGRADE_FROM states how far back an upgrade can start, and the floors for Ruby and Node are read from .ruby-version and package.json, checked before a merge.

0.x until someone outside installs it: while it is 0.x, anything can change between releases.