- Notifications
You must be signed in to change notification settings - Fork1.2k
Remove "latest" and friends#1294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Major version upgrades in PostgreSQL are complicated, 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).
This is somewhat related to#797, in that it's an attempt to make sure the generic tag aliases we provide are only ones thatcan 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). |
$ diff -u <(bashbrew cat postgres) <(bashbrew cat <(./generate-stackbrew-library.sh))--- /dev/fd/632024-12-02 15:16:32.798306973 -0800+++ /dev/fd/622024-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/632024-12-02 15:17:20.054798899 -0800+++ /dev/fd/622024-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 |
The full list of tags I am proposing removing from Docker Hub, for total completeness: $crane ls postgres| grep -E'^[^0-9]'alpinealpine3.13alpine3.14alpine3.15alpine3.16alpine3.17alpine3.18alpine3.19alpine3.20bookwormbullseyebusterlatest |
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? |
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 doingis 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 request2024-12-03 21:52:06.803 UTC [1] LOG: aborting any active transactions2024-12-03 21:52:06.807 UTC [1] LOG: background worker "logical replication launcher" (PID 65) exited with exit code 12024-12-03 21:52:06.807 UTC [60] LOG: shutting down2024-12-03 21:52:06.809 UTC [60] LOG: checkpoint starting: shutdown immediate2024-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/14EA3402024-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:17PostgreSQL Database directory appears to contain a database; Skipping initialization2024-12-03 21:52:37.599 UTC [1] FATAL: database files are incompatible with server2024-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 |
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.20COPY deprecated.sh /usr/local/binENTRYPOINT ["deprecated.sh"]CMD ["docker-entrypoint.sh","postgres"] #!/usr/bin/env bashset -Eeo pipefailecho>&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 |
I like@yosifkit suggestion!! |
justinclift commentedJan 5, 2025
Alternatively, is providing docker images that automatically upgrade a feasible direction instead? 😄 The question has been asked a few times in various places, but there's not been any public discussion about it which seems kind of unusual for such a potential improvement. |
Unfortunately, automated upgrades are complex enough (and opinionated enough) that it is not something we're comfortable maintaining officially here, especially without involvement and assistance from someone upstream (we already maintain a significant amount of code above and beyond a standard PostgreSQL installation, and it's frankly more than we'd like it to be as-is). |
Converting to draft because I agree with@yosifkit's suggestion, although implementing it is less trivial than deleting |
justinclift commentedJan 7, 2025
No worries. Thanks for considering it and letting us know the outcome. 😄 |
justinclift commentedJan 7, 2025
Just to check, what sort of involvement and assistance would be needed? Itmight be possible to get that happening. 😄 |
The |
The danger of corrupting a db imo far outweigh the benefits to CI pipelines. |
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).