Skip to content
KenresoftKenresoft Docs

Versions and Releases

Kenresoft CMS ships as numbered releases: v0.9.0, v0.9.1, v0.10.0 and so on. A release is a fixed, tested snapshot of the code. Everything that isn’t in a release yet is still in development and never reaches your deployment unless you ask for it.

Where What it is for
Changelog What changed in each release, including anything you must do when updating
Update the CMS How to move a deployment to a new release
Settings → Updates in the admin Which release a deployment runs, and whether a newer one exists
GitHub releases The same notes, and the code of every release

A new install (npm create @kenresoft-cms@latest) always starts on the latest release. From then on, pnpm run update moves it to newer ones.

Which version am I running?

Section titled “Which version am I running?”

Open Settings → Updates in the admin. It shows:

  • The version this deployment runs, for example v0.9.0.
  • Up to date, or Update available with the newer version and a link to its notes.

Only Admins and Owners see it; they also get an Update available notice in the sidebar. The version is never shown on a public endpoint, since an exact version helps attackers target known issues.

In the CMS project itself, the version field of the root package.json is the same number.

How the update check works

Section titled “How the update check works”

The API Worker asks GitHub for the latest release and caches the answer for 6 hours (1 hour if GitHub couldn’t be reached). So a new release can take up to 6 hours to show as Update available; pnpm run update always sees it immediately.

A fork that publishes its own releases points the check at its own repository by adding UPDATE_CHECK_REPO = "your-org/your-fork" under [vars] in wrangler.toml. UPDATE_CHECK_REPO = "off" turns the check off; the admin still shows the running version.

What the version numbers mean

Section titled “What the version numbers mean”

Releases follow semantic versioning. Before 1.0, the middle number marks breaking changes, as is usual for 0.x software:

Release Contains Before updating
Patch: 0.9.1 → 0.9.2 Fixes only Nothing to do
Minor: 0.9.x → 0.10.0 New features, database migrations and, before 1.0, breaking changes Read the notes, especially any Breaking or Migration section
Major, from 1.0 Breaking changes Follow the steps in the Breaking section

Skipping releases is fine: pnpm run update applies every migration in between and prints the notes of every release you skipped. Read them all before updating a production deployment.

Rolling back

Section titled “Rolling back”

pnpm run update never moves an install to an older release. Database migrations only run forwards, and older code may not understand a newer database. Prefer waiting for a fix release.

If you must go back:

  1. Restore the database to a point before the update with D1 Time Travel. Content saved after that point is lost.
  2. In the CMS project, check out the older release and reinstall: git checkout v0.9.0, then pnpm install.
  3. Deploy both Workers by hand, as described in Cloudflare deployment.

When a fix release is out, return to your branch (git checkout main) and run pnpm run update.

Upgrade guides

Section titled “Upgrade guides”

Some releases change how things work in a way that needs more than a changelog entry: