Versioning
What SpipCP's version number means — an authored semver release, not a counter — how it differs from the deployed image tag, and why phase numbers are internal and never describe the product.
SpipCP has one version number that means anything externally: the release, a semver like 1.4.0,
written by a human and published in the changelog. Everything else that may appear —
an image tag, a folder name in the repository, a number in a commit message — is bookkeeping, and this
page exists to say which is which.
The product line starts at 0.7 and is currently 1.4.
A “phase 2.9” reference anywhere is not a version
Phase numbers are internal spec IDs. They are not product versions and never were. The repository
numbers its plans — Docs/versions/3.0/, feat(phase-3.0): … — so that the people building SpipCP
can find the document that describes a change. Those numbers count plans written, not software
earned, so they run far ahead of what the product actually is: at the time of writing, twenty-four
phases had shipped and the software was honestly a 1.4. Nothing in the running panel has ever
claimed to be "v2.9". A phase number that leaked into these docs and read like a version was a
mistake, corrected on this page.
Releases are authored, not counted
A release is written by a person: a version, a title, a severity, and a list of items. It is not derived
from how many commits landed, how many features shipped, or which internal plan is current. That means
the number is allowed to say something true — a quiet quarter can be 1.4.1 even if a hundred commits
went into it, and a version does not inflate simply because time passed.
Pre-1.0 the line is 0.MINOR.PATCH, and pre-1.0 means what it always means: the shape of things could
still move. 1.0.0 was a decision, not a milestone a counter arrived at.
Severity: what a number change signals
| Severity | The version moves | What it means |
|---|---|---|
| Major | 1.4.0 → 2.0.0 | A depended-on behavior changed. Read the notes before updating. |
| Minor | 1.3.2 → 1.4.0 | New capability, backwards compatible. Update at any time. |
| Patch | 1.4.0 → 1.4.1 | Fixes only. No configured behavior changes. |
The changelog shows the severity as a chip beside each release, so "is this the one I have to read?" is answerable at a glance.
The image tag is not the version
SPIPCP_TAG in .env identifies a build artifact — which image a box pulls and runs. The
release version identifies what the software claims to be. Usually they match, because a release is
tagged with its own version; when they do not, the changelog is right and the tag is just a filename.
SPIPCP_TAG=v1.4.0— the box is running the artifact cut for release 1.4.0.SPIPCP_TAG=latest— the box is running whatever the latest artifact is. The panel still knows which release that is: the feed'scurrentVersionanswers it.SPIPCP_TAG=local— the image was built from source. There is no artifact to match.
The badge at the top of the changelog reads the running panel and shows both. Deploying and pinning a tag is covered in Installation.
Where the versions live
Release notes are written in the panel — Admin → Changelog — held as rows, and published as a single public JSON feed. This docs page is a consumer of that feed, not a second copy of it. That is deliberate: hand-maintained changelog files drift from each other, and this one cannot, because there is only one.
→ Consume it directly: Changelog API.