Remove "latest" and friends

[tianon]

Major version upgrades in PostgreSQL are complicated (#37, most recently #1293), and no users should be pulling a version of PostgreSQL without explicitly specifying an intentional major version (thus avoiding tools like compose or watchtower from naïvely "upgrading" them and breaking the database).

[tianon]

This is somewhat related to #797, in that it's an attempt to make sure the generic tag aliases we provide are only ones that can be successfully updated (see also #582 and how we handled that in a similar/consistent way).

My intention, if @yosifkit agrees, is to also apply this retroactively by deleting generic aliases from Hub as well (so users of them get a clear and explicit signal that they need to adjust the way they are consuming these).

[tianon]

$ diff -u <(bashbrew cat postgres) <(bashbrew cat <(./generate-stackbrew-library.sh))
--- /dev/fd/63	2024-12-02 15:16:32.798306973 -0800
+++ /dev/fd/62	2024-12-02 15:16:32.798306973 -0800
@@ -1,22 +1,22 @@
 Maintainers: Tianon Gravi <admwiggin@gmail.com> (@tianon), Joseph Ferguson <yosifkit@gmail.com> (@yosifkit)
 GitRepo: https://github.com/docker-library/postgres.git
 
-Tags: 17.2, 17, latest, 17.2-bookworm, 17-bookworm, bookworm
+Tags: 17.2, 17, 17.2-bookworm, 17-bookworm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, mips64le, ppc64le, s390x
 GitCommit: 0b87a9bbd23f56b1e9e863ecda5cc9e66416c4e0
 Directory: 17/bookworm
 
-Tags: 17.2-bullseye, 17-bullseye, bullseye
+Tags: 17.2-bullseye, 17-bullseye
 Architectures: amd64, arm32v7, arm64v8, i386
 GitCommit: 0b87a9bbd23f56b1e9e863ecda5cc9e66416c4e0
 Directory: 17/bullseye
 
-Tags: 17.2-alpine3.20, 17-alpine3.20, alpine3.20, 17.2-alpine, 17-alpine, alpine
+Tags: 17.2-alpine3.20, 17-alpine3.20, 17.2-alpine, 17-alpine
 Architectures: amd64, arm32v6, arm32v7, arm64v8, i386, ppc64le, riscv64, s390x
 GitCommit: 0b87a9bbd23f56b1e9e863ecda5cc9e66416c4e0
 Directory: 17/alpine3.20
 
-Tags: 17.2-alpine3.19, 17-alpine3.19, alpine3.19
+Tags: 17.2-alpine3.19, 17-alpine3.19
 Architectures: amd64, arm32v6, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 0b87a9bbd23f56b1e9e863ecda5cc9e66416c4e0
 Directory: 17/alpine3.19

$ diff -u <(bashbrew list postgres) <(bashbrew list <(./generate-stackbrew-library.sh) | sed -re 's/^[0-9]+/postgres/')
--- /dev/fd/63	2024-12-02 15:17:20.054798899 -0800
+++ /dev/fd/62	2024-12-02 15:17:20.054798899 -0800
@@ -1,21 +1,15 @@
 postgres:17.2
 postgres:17
-postgres:latest
 postgres:17.2-bookworm
 postgres:17-bookworm
-postgres:bookworm
 postgres:17.2-bullseye
 postgres:17-bullseye
-postgres:bullseye
 postgres:17.2-alpine3.20
 postgres:17-alpine3.20
-postgres:alpine3.20
 postgres:17.2-alpine
 postgres:17-alpine
-postgres:alpine
 postgres:17.2-alpine3.19
 postgres:17-alpine3.19
-postgres:alpine3.19
 postgres:16.6
 postgres:16
 postgres:16.6-bookworm

[tianon]

The full list of tags I am proposing removing from Docker Hub, for total completeness:

$ crane ls postgres | grep -E '^[^0-9]'
alpine
alpine3.13
alpine3.14
alpine3.15
alpine3.16
alpine3.17
alpine3.18
alpine3.19
alpine3.20
bookworm
bullseye
buster
latest

[LaurentGoderre]

This might break a lot of builds though. Could we handle this via the entrypoint script instead and close the container if it detects an difference in major versions?

[tianon]

That's essentially what happens today, except it's PostgreSQL itself that does the exiting. In other words, the breaking change is actually the point -- these "builds" we're breaking are doing something wrong, and this is one of the only levers we have to communicate that to them (by making it clear that the thing they're doing is unsupported).

$ docker run -it --rm -v test:/var/lib/postgresql/data --env POSTGRES_PASSWORD=password postgres:16
...
2024-12-03 21:52:04.899 UTC [1] LOG:  database system is ready to accept connections
^C2024-12-03 21:52:06.797 UTC [1] LOG:  received fast shutdown request
2024-12-03 21:52:06.803 UTC [1] LOG:  aborting any active transactions
2024-12-03 21:52:06.807 UTC [1] LOG:  background worker "logical replication launcher" (PID 65) exited with exit code 1
2024-12-03 21:52:06.807 UTC [60] LOG:  shutting down
2024-12-03 21:52:06.809 UTC [60] LOG:  checkpoint starting: shutdown immediate
2024-12-03 21:52:06.837 UTC [60] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.006 s, sync=0.002 s, total=0.030 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB; lsn=0/14EA340, redo lsn=0/14EA340
2024-12-03 21:52:06.847 UTC [1] LOG:  database system is shut down

$ docker run -it --rm -v test:/var/lib/postgresql/data postgres:17

PostgreSQL Database directory appears to contain a database; Skipping initialization

2024-12-03 21:52:37.599 UTC [1] FATAL:  database files are incompatible with server
2024-12-03 21:52:37.599 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2 (Debian 17.2-1.pgdg120+1).

$ echo $?
1

[yosifkit]

I am on board with deprecating the tags that don't specify a PostgreSQL version, but perhaps users need more lead time and direction than just the tags no longer existing in a week (or whatever timeline).

🤔 Perhaps replace the (currently supported) generic tags with an image that prints a large deprecation notice and sleeps before continuing? Something like this?

FROM postgres:17-alpine3.20
COPY deprecated.sh /usr/local/bin
ENTRYPOINT ["deprecated.sh"]
CMD ["docker-entrypoint.sh", "postgres"]

#!/usr/bin/env bash
set -Eeo pipefail

echo >&2 "insert heinous warnings of pending 'postgres:alpine3.20' / 'alpine' image alias deprecation, use '17-alpine3.20' instead"
sleep 30 # an arbitrarily long time (but not so long to make our own tests too slow)
exec "$@"

Without shadowing the postgres binary itself, I'm not sure how to catch users that replace the entrypoint with their own script, but I guess those are the power users anyway.

[LaurentGoderre]

I like @yosifkit suggestion!!