Publish an image for every push to a milestone branch

.github/workflows/docker.yml

@@ -8,6 +8,13 @@ on:
     #    deployment follows. This builds amd64 ONLY — one job — because that
     #    deployment is amd64 and the arm64 image is a release artifact nobody
     #    pulls from `main`.
+    #  - A push to a milestone branch does the same under that branch's name:
+    #    `milestone/v0.3.8` publishes `milestone-v0.3.8` (the metadata action
+    #    turns the slash into a dash) and `sha-…`, so an install can follow a
+    #    release before it reaches `main`. Never `latest` and never the
+    #    catalogue, which move on a `v*` tag alone. A push runs the workflow
+    #    file of the commit pushed, so a milestone branch publishes once `main`
+    #    with this line has been merged into it.
     #  - A `v*` tag builds the published release: amd64 + arm64, merged into one
     #    manifest, tagged with the version, `0.0`, and `latest` — and then
     #    publishes the GitHub Release that announces it (the `release` job).
@@ -17,7 +24,7 @@ on:
     # prove the Dockerfile compiles twice and push nothing. Use
     # workflow_dispatch to build an untagged commit by hand.
     push:
-        branches: [main]
+        branches: [main, 'milestone/**']
         tags: ['v*']
     workflow_dispatch:
 

CHANGELOG.md

@@ -4,7 +4,8 @@ Notable changes per release. plMail runs its migrations automatically on boot,
 so anything that changes the schema irreversibly is called out explicitly.
 
 The published image tags: `latest` follows the most recent release below,
-`main` follows the tip of the default branch, and `sha-…` pins one commit.
+`main` follows the tip of the default branch, `milestone-vX.Y.Z` the work collected for that
+release before it reaches `main`, and `sha-…` pins one commit.
 
 ## v0.3.7 — 2026-10-20
 

docs/de/install/upgrading.md

@@ -1,4 +1,4 @@
-<!-- translated-from: install/upgrading.md sha1:3b59d99e47f165dc137b889aa6021578afea1e24 -->
+<!-- translated-from: install/upgrading.md sha1:8843e5bc0db3bd70577a5d29c566a6d5db35b950 -->
 # Aktualisieren
 
 plMail migriert seine eigene Datenbank beim Start. Diese eine Entscheidung prägt alles auf dieser
@@ -51,6 +51,7 @@ Der Release-Workflow veröffentlicht ein Multi-Architektur-Manifest und richtet
 |---|---|
 | `latest` | der jüngsten **Veröffentlichung** — er bewegt sich nur, wenn ein `v*`-Tag gepusht wird |
 | `main` | der Spitze des Standard-Branches, veröffentlicht oder nicht |
+| `milestone-v0.3.8` | der Arbeit, die für eine Veröffentlichung auf ihrem Milestone-Branch gesammelt wird, bevor sie `main` erreicht. Zum frühen Ausprobieren einer Veröffentlichung; er kann Migrationen enthalten, die `main` noch nicht hat, deshalb ist der Weg zurück zu `main` nicht immer möglich |
 | `0.0.16` | einer Veröffentlichung, festgenagelt. Ohne führendes `v`: Der Git-Tag heißt `v0.0.16`, der Image-Tag nicht |
 | `0.0` | dem neuesten Patch einer Minor-Linie |
 | `sha-1a2b3c` | einem Commit, exakt festgenagelt |

docs/install/upgrading.md

@@ -48,6 +48,7 @@ The release workflow publishes one multi-architecture manifest and points severa
 |---|---|
 | `latest` | the most recent **release** — it moves only when a `v*` tag is pushed |
 | `main` | the tip of the default branch, released or not |
+| `milestone-v0.3.8` | the work collected for one release on its milestone branch, before it reaches `main`. For trying a release early; it can carry migrations `main` does not have yet, so going back to `main` from it is not always possible |
 | `0.0.16` | one release, pinned. No leading `v`: the git tag is `v0.0.16`, the image tag is not |
 | `0.0` | the newest patch of one minor line |
 | `sha-1a2b3c` | one commit, pinned exactly |