2.4 KiB
2.4 KiB
Upstream sources — mattermost-lts
| service | image | source repo | releases / changelog |
|---|---|---|---|
| app | mattermost/mattermost-team-edition | https://github.com/mattermost/mattermost | https://docs.mattermost.com/about/mattermost-changelog.html |
| postgres | postgres | https://github.com/postgres/postgres | https://www.postgresql.org/docs/release/ |
Standing notes
- mattermost-lts tracks the 10.11 ESR (Extended Support Release). Release calendar:
- 10.11 = current ESR, supported through 2026-08-15; latest patch: 10.11.19 (2026-05-27)
- 10.12 = innovation release, support EXPIRED December 2025 — do NOT target
- 11.7 = next ESR (supported through 2027-05-15) — future major upgrade, separate planning needed
- Check the release lifecycle at https://endoflife.date/mattermost before each upgrade run.
The
release-10.11Docker Hub floating tag always points to the latest 10.11.x patch.
- postgres: stay on 15-alpine for now. The upgrade to 16-alpine requires a major-version migration (pg_upgrade or dump/restore with operator involvement) because the stack runs with a persistent postgres_data volume. A 16 container against pg15 PGDATA crashes on startup. Major pg bump is a separate operator-guided step.
- The backup/restore hooks are INLINED in compose.yml
deploy.labels(not a separate pg_backup.sh Docker config). This was intentional: using a Docker config caused a timing race where backupbot could exec into the OLD postgres container (pre-config-update) during the upgrade lifecycle. Inline commands eliminate this dependency — the backupbot reads labels from the Docker service API (always current), and pg_dump/psql/createdb are present in any postgres:alpine container. - Backup format (as of 2.1.12+10.11.19): gzip-compressed
backup.sqlin the postgres_data volume. The restore hook properly terminates connections, drops + recreates the DB, then gunzips + restores.DROP DATABASE WITH (FORCE)requires PostgreSQL 13+ — safe on postgres:15-alpine.