Consider adding postgis/postgis:<postgres_major_version>-<postgis_major_version> tags

[maxfenv]

Hi!

It would be useful if there existed a tag that one could specify that always points at the latest possible release for a particular postgres/postgis major version combo. That way maintenance overhead in downstream docker compose files for example could be somewhat minimised.

Is there interest in this? I obviously have an interest and I'm quite happy to look into it and make some contributions to the extent that I am able. I don't know if this creates a maintenance headache for you going forwards though!

Example

postgis/postgis:15-3-alpine as an alias (currently) of postgis/postgis:15-3.5-alpine. When postgis 3.6 is released, 15-3-alpine would point at 15-3.6-alpine instead

Motivation

We had been pinning our postgis containers to postgis/postgis:15-3.3-alpine. Unnoticed to us, it's been over a year since that tag has seen any updates. We should have been keeping up with the postgis minor versions instead and should be on 15-3.5-alpine by now. This is entirely our own fault of course, but did take me by surprise.

In the case of other docker images, it is often possible to just point at a stable tag, or at least a tag that only specifies a major version, which is an alias for the most recently release with that major version. registry.redict.io/redict:7-alpine, or nginx:stable for instance. I know that a stable tag for postgres doesn't really work, since upgrading postgres requires manual intervention.

[maxfenv]

Not that I'm familiar with github workflows at all, but given that image building is completely automated that way, presumably just pushing some additional tags as those aliases would be easy enough to add here: https://github.com/postgis/docker-postgis/blob/master/.github/workflows/main.yml

[maxfenv]

Begging your pardon, the actual building, tagging and pushing is happening in the makefile: https://github.com/postgis/docker-postgis/blob/master/Makefile

[ImreSamu]

Thank you for your suggestion

Your idea has a rational basis, but many other factors must be considered and carefully evaluated before a final decision is made.

• In the upstream docker postgres repository, there is an ongoing discussion about removing similar tags Therefore, any similar changes here should be thoroughly considered.

  • see: https://github.com/docker-library/postgres/pull/1294

• If someone wishes to automatically upgrade an existing PostGIS database from 3.3 to 3.4 to 3.5, the command SELECT postgis_extensions_upgrade(); should also be executed automatically. In other words, we need a solution that works perfectly for CI while ensuring that an average user with minimal technical knowledge is not overwhelmed.

• In the test repository, I am already generating several Docker tags:

  • 17-3.5-bookworm 17-3.5.2-bookworm 17-3.5 latest

  • https://github.com/ImreSamu/docker-postgis/blob/3e534ccd63d61a76328ec72187f34df8a7f07aae/17-3.5/bookworm/tags#L1

  • We could even add an extra tag: 17-3-bookworm , which I believe would solve the CI problem; however, this should be considered more thoroughly.

• PostGIS images are generally regenerated weekly . Therefore, if someone downloads the PostGIS image automatically via GitHub CI using docker pull, it is advisable to check the image's creation date. If the image is older than 1-2 months, it may even cause error messages. Based on this, a simple workaround could be developed.

simple workaround example

$ docker pull postgis/postgis:15-3.4-alpine && \
> created=$(docker inspect --format='{{.Created}}' postgis/postgis:15-3.4-alpine) && \
> days=$(( ( $(date +%s) - $(date --date="$created" +%s) ) / 86400 )) && \
> echo "postgis/postgis:15-3.4-alpine - generated ${days} days ago" && \
> [ ${days} -le 40 ] || { echo "it is too old" >&2; false; }
15-3.4-alpine: Pulling from postgis/postgis
Digest: sha256:d96be3a9c16d44e22d34d5c7b6e85be8875addf672672c6cd38171ea6055a94a
Status: Image is up to date for postgis/postgis:15-3.4-alpine
docker.io/postgis/postgis:15-3.4-alpine
postgis/postgis:15-3.4-alpine - generated 123 days ago
it is too old

[maxfenv]

Thank you for your detailed response!

If someone wishes to automatically upgrade an existing PostGIS database from 3.3 to 3.4 to 3.5, the command SELECT postgis_extensions_upgrade(); should also be executed automatically. In other words, we need a solution that works perfectly for CI while ensuring that an average user with minimal technical knowledge is not overwhelmed.

I had in fact forgotten about the fact that postgis upgrades are not automatic in that way! That alone should be enough reason to close this as wontfix to be honest.