chore(ci): publish latest from main and retire the edge tag (#711)

* fix(docs): update versioning strategy and tag policies for Docker images

* fix(docs): clarify versioning strategy in environment configuration
fix(docker): update docker-push script to remove local latest tag handling

* fix(docs): clarify VERSION variable usage in Docker push script
This commit is contained in:
Abdulmuizz Hamzat
2026-07-07 12:59:33 +01:00
committed by GitHub
parent e8181b296b
commit 2e402efa78
7 changed files with 26 additions and 35 deletions
+7 -9
View File
@@ -57,8 +57,8 @@ Check your Docker Hub repository at:
The workflow will automatically publish images when:
1. **Push to `main`**: Publishes the **`edge`** tag only (does NOT move `latest`).
2. **Push a version tag `vX.Y.Z`**: Publishes `X.Y.Z`, `X.Y`, `X`, and `latest`.
1. **Push to `main`**: Publishes the **`latest`** tag (the freshest `main` build).
2. **Push a version tag `vX.Y.Z`**: Publishes `X.Y.Z`, `X.Y`, `X` (immutable, pinned releases).
3. **Manual trigger**: Use the Actions tab in GitHub.
Every build is **boot smoke-tested** (started against ephemeral postgres + redis, healthcheck
@@ -107,7 +107,7 @@ docker pull classroomio/dashboard:latest
For self-hosting with Docker Compose, see [SELF_HOST.md](SELF_HOST.md). The setup uses a single root `.env` file and `docker-compose.yaml`.
## Versioning Strategy (stable-releases + edge)
## Versioning Strategy (rolling `latest` + pinned releases)
The published tags and what they mean:
@@ -115,17 +115,15 @@ The published tags and what they mean:
|-----|--------------|---------|
| `1.4.2` (exact) | a `v1.4.2` git tag | Immutable, smoke-tested release — **what production should pin** |
| `1.4`, `1` | a `v1.4.2` git tag | Latest patch/minor of that line |
| `latest` | a `v*` git tag only | The newest *released* version |
| `edge` | every push to `main` | Bleeding edge; may be unstable |
| `latest` | every push to `main` | The freshest `main` build (rolling; may include unreleased code) |
The key rule: **`latest` is never moved by a routine merge to `main`** — only a deliberate release
tag moves it. Self-hosters pin `CIO_VERSION` (see [SELF_HOST.md](SELF_HOST.md)) and upgrade on their
own schedule.
The key rule: **`latest` moves on every merge to `main`**, so it can change under you. Self-hosters
pin `CIO_VERSION` (see [SELF_HOST.md](SELF_HOST.md)) and upgrade on their own schedule.
### Cutting a release
Versioning is driven by git tags; the CI workflow does the rest (build multi-arch → smoke-test →
push `X.Y.Z`/`X.Y`/`X`/`latest`).
push `X.Y.Z`/`X.Y`/`X`). `latest` is published separately, on every merge to `main`.
```bash
# Bump version + create the vX.Y.Z tag from the repo's changelog tooling
+4 -6
View File
@@ -44,18 +44,16 @@ From a full clone you can also use the helper: `./run-docker-full-stack.sh --ima
## Versioning & Upgrades
Published images use a **stable-releases + edge** tag policy:
Published images use a **rolling `latest` + pinned releases** tag policy:
| Tag | Meaning | Use it for |
|-----|---------|-----------|
| `1.4.2` (exact) | An immutable, smoke-tested release | **Production — always pin this** |
| `1.4`, `1` | Latest patch/minor of that line | Tracking a line |
| `latest` | The newest *released* version | Trying it out |
| `edge` | The last `main` build (may be unstable) | Testing upcoming changes |
| `latest` | The freshest `main` build (rolling; may include unreleased code) | Trying the newest code |
`latest` only moves when a real release is tagged — a routine merge to `main` publishes `edge`, never
`latest`. **Pin `CIO_VERSION` to an exact version in production** so a new release can't break you
unattended.
`latest` moves on **every merge to `main`**, so it can change under you. **Pin `CIO_VERSION` to an
exact version in production** so a merge can't break you unattended.
```bash
# Upgrade: bump the version, pull, recreate