Stage 0 of docs/audit-2026-10-12.md, 7/7: the release image says which release it is (H1), the e2e module is compiled on every push (M20), test/ is out of the build context (L33), the documents say the 2.x image is not published and show the local build (M6), dependencies raised, staticcheck clean, the negative e2e cases held to their own refusals (which showed the level-1 rate-limit case had never seen the limit). CHANGELOG cut; pin 2.4.2 in deploy/docker-compose.yml, README (with the local-build note), guide; development.md "from pin" and the planned cuts of the audit's stages (2.5.0 ... 2.6.0); roadmap row in progress and the recommended order; stage 0 marked shipped in the plan. No tag (the owner's command only). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -543,7 +543,7 @@ card, and it is not planned) are mockup-first; a migration the test server
|
||||
has already run is never edited — the next file is added; the published
|
||||
`1.x` tags and images are history and are not touched.
|
||||
|
||||
### Stage 0 — release hygiene (no product code) → `2.4.2`
|
||||
### Stage 0 — release hygiene (no product code) → `2.4.2` (shipped 2026-10-14)
|
||||
|
||||
- [x] **Stamp the right version** (H1). Make the e2e build take the version from
|
||||
the environment (`VERSION: ${SELFPOST_E2E_VERSION:-e2e}` in
|
||||
|
||||
+7
-1
@@ -107,7 +107,7 @@ than the default «meaningful step» rule in [§ Commits and release build](#com
|
||||
2. Git tag `vX.Y.Z` and publish the GitHub Release only on explicit request (see
|
||||
[§ Release image](#release-image)).
|
||||
|
||||
**Planned version cuts** (from pin `2.4.1`; adjust if semver changes mid-track):
|
||||
**Planned version cuts** (from pin `2.4.2`; adjust if semver changes mid-track):
|
||||
|
||||
| Stage | ID | Cut |
|
||||
|---|---|---|
|
||||
@@ -130,6 +130,12 @@ than the default «meaningful step» rule in [§ Commits and release build](#com
|
||||
| 17 | panel-notifications | `2.3.0` |
|
||||
| 18 | from-header-binding | `2.4.0` |
|
||||
| 19 | code audit 2026-10-12 and its plan (docs only, owner-requested cut) | `2.4.1` (PATCH) |
|
||||
| 20 | audit-2026-10-12 stage 0: release hygiene | `2.4.2` (PATCH) |
|
||||
| 21 | audit-2026-10-12 stages 1 and 2 | `2.5.0` |
|
||||
| 22 | audit-2026-10-12 stage 2b: the log tailer | `2.5.1` |
|
||||
| 23 | audit-2026-10-12 stage 3 | `2.5.2` |
|
||||
| 24 | audit-2026-10-12 stage 4 | `2.5.3` |
|
||||
| 25 | audit-2026-10-12 stage 5 | `2.6.0` |
|
||||
|
||||
Docs-only prep (checklists in plans, no product code) uses the same per-step
|
||||
commit rule but **no** version cut until the next product stage ships.
|
||||
|
||||
+3
-3
@@ -184,14 +184,14 @@ cat ./data/setup-token
|
||||
#### Fixed image tag
|
||||
|
||||
`deploy/docker-compose.yml` pins an explicit version (`ghcr.io/mixeme/selfpost:X.Y.Z`),
|
||||
deliberately never `:latest`. The current pin is `2.4.1`. **No 2.x image is
|
||||
deliberately never `:latest`. The current pin is `2.4.2`. **No 2.x image is
|
||||
published on ghcr.io yet** (the newest there is `1.3.0`); until one is, build
|
||||
it from the checkout under the pinned name, and Compose uses the local image
|
||||
instead of pulling:
|
||||
|
||||
```sh
|
||||
docker build -f build/Dockerfile --build-arg VERSION=2.4.1 \
|
||||
-t ghcr.io/mixeme/selfpost:2.4.1 .
|
||||
docker build -f build/Dockerfile --build-arg VERSION=2.4.2 \
|
||||
-t ghcr.io/mixeme/selfpost:2.4.2 .
|
||||
```
|
||||
|
||||
`VERSION` must equal the tag: it is the version the backup check compares
|
||||
|
||||
+3
-2
@@ -42,14 +42,15 @@ in `git log` and [CHANGELOG.md](../CHANGELOG.md).
|
||||
| from-header-binding | Hold a message's `From:` header against the application that sends it | shipped `2.4.0` | 9/9 | [plans/from-header-binding.md](plans/from-header-binding.md) |
|
||||
| panel-redesign | Panel redesign (accepted mockups, design contract) | shipped `2.0.0` | 27/27 | [plans/panel-redesign.md](plans/panel-redesign.md) |
|
||||
| schema-squash | Squash SQLite migrations into a 2.x baseline | built in panel-redesign (stage 1) | — | [plans/panel-redesign.md](plans/panel-redesign.md) |
|
||||
| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | agreed (2026-10-12: stage 0 first, then 1+2; the rest after) | 7/61 | [audit-2026-10-12.md](audit-2026-10-12.md) |
|
||||
| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | in progress (stage 0 shipped `2.4.2`; next stages 1+2 → `2.5.0`) | 7/61 | [audit-2026-10-12.md](audit-2026-10-12.md) |
|
||||
|
||||
**Recommended order** (not binding; owner, 2026-10-09: feature order follows
|
||||
development convenience): **panel-redesign** shipped as `2.0.0` (2026-10-11) and
|
||||
**inbound-antispam-panel** as `2.1.0` (2026-10-12), built in the new component
|
||||
kit — styling its two screens once instead of twice. **delivery-log-storage**
|
||||
shipped as `2.2.0` the same day, **panel-notifications** as `2.3.0` and
|
||||
**from-header-binding** as `2.4.0`.
|
||||
**from-header-binding** as `2.4.0`. Stage 0 of
|
||||
[audit-2026-10-12](audit-2026-10-12.md) shipped as `2.4.2` (2026-10-14).
|
||||
Nothing is agreed after it: every remaining
|
||||
item is a candidate. panel-docs shipped in
|
||||
[CHANGELOG.md](../CHANGELOG.md) `[1.8.0]`; dmarc-reports in `[1.7.0]`
|
||||
|
||||
Reference in New Issue
Block a user