Versioning and Releases

Versioning and Releases

Anichron images follow Semantic Versioning (MAJOR.MINOR.PATCH). Git tags on the master branch drive all Docker image releases — there is no manual tagging step in the CI configuration itself.

---

Development phases

Phase	Meaning	First release
Dev	Active development, no stability guarantee	From the first commit
Beta	Core product works end-to-end; used in practice, bugs expected	After Epic 6 (Flashback UI)
Stable	Production-ready 1.0.0 release	After Epics 7–8 are complete or explicitly deferred

---

Docker image tags

Dev builds (every merge to master)

Tag	Type	Description
edge	Floating	Always points to the latest master build. Moves on every merge.
sha-abc1234	Immutable	Short SHA of the exact commit. Never changes.

Beta releases

Tag	Type	Description
1.0.0-beta.1	Immutable	Exact pre-release version. Never changes.
sha-abc1234	Immutable	Short SHA of the exact commit.

latest, 1, and 1.0 are not applied to pre-release tags. edge is not re-applied at tag time — it already points to the commit from the earlier merge.

Stable releases

Tag	Type	Description
1.0.0	Immutable	Exact version. Never changes.
1.0	Floating	Latest patch in the 1.0.x line. Moves when 1.0.1 is tagged.
1	Floating	Latest minor in the 1.x line. Moves when 1.1.0 is tagged.
latest	Floating	Latest stable release ever. Moves on every new stable tag.
sha-abc1234	Immutable	Short SHA of the exact commit.

---

Full lifecycle example

merge to master     →  edge
                        sha-f3a1b2c

merge to master     →  edge   (moves — now points to this commit)
                        sha-9d4e5f6

git tag v1.0.0-beta.1
git push origin v1.0.0-beta.1
                    →  1.0.0-beta.1
                        sha-9d4e5f6
                       (edge stays here, does not move)

merge to master     →  edge   (moves again — new commit)
                        sha-7c8d9e0

git tag v1.0.0-beta.2
git push origin v1.0.0-beta.2
                    →  1.0.0-beta.2
                        sha-7c8d9e0

git tag v1.0.0
git push origin v1.0.0
                    →  1.0.0
                        1.0
                        1
                        latest
                        sha-7c8d9e0

---

How to cut a release

Prerequisites

• The commit you want to release is already merged to master.
• Your local master is up to date: git pull origin master

Beta release

git tag v1.0.0-beta.1
git push origin v1.0.0-beta.1

GitHub Actions detects the tag push and builds + pushes the image automatically. Check the Actions tab for progress.

Stable release

git tag v1.0.0
git push origin v1.0.0

This applies 1.0.0, 1.0, 1, latest, and the short SHA. No other steps required.

Patch release

git tag v1.0.1
git push origin v1.0.1

1.0 and 1 float forward to this tag. 1.0.0 remains unchanged.

---

Tag format

Tags must match vMAJOR.MINOR.PATCH or vMAJOR.MINOR.PATCH-LABEL.N:

Example	Type
v1.0.0	Stable release
v1.0.1	Patch release
v1.1.0	Minor release
v1.0.0-beta.1	Beta pre-release
v1.0.0-beta.2	Second beta iteration
v2.0.0-beta.1	Beta for a major version

Tags that do not match v*.*.* are ignored by the pipeline.

---

Choosing the right image for your environment

Environment	Recommended tag	Reason
Local dev / always-latest	edge	Tracks every master build
Staging / integration test	1.0.0-beta.2 (exact)	Stable reference during testing
Production	1.0.0 (exact) or 1.0	Immutable exact version is safest; 1.0 picks up patches automatically
Automated production updates	1.0	Receives patch releases without manual intervention

Avoid using latest in docker-compose.yml for production — it moves on every stable release and can cause unintended upgrades.