diff --git a/cc-ci-plan/upstream/mattermost-lts.md b/cc-ci-plan/upstream/mattermost-lts.md new file mode 100644 index 0000000..6e7eada --- /dev/null +++ b/cc-ci-plan/upstream/mattermost-lts.md @@ -0,0 +1,20 @@ +# 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.x LTS series** — do NOT bump to 11.x (major version, breaking changes). + The latest 10.x tag is on `mattermost/mattermost-team-edition` e.g. `10.11.x`; check release notes + at https://docs.mattermost.com/about/mattermost-changelog.html. +- 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.