Specific tags for each Postgis version

[edwardsamuel]

I think it is better to have specific tags for each Postgis version, like:

• 9.1-2.1
• 9.2-2.1
• 9.3-2.1
• 9.4-2.1
• 9.5-2.1
• 9.4-2.2
• 9.5-2.2
• 9.4 --> using PostgreSQL 9.4 and latest Postgis version
• 9.5 --> using PostgreSQL 9.5 and latest Postgis version
• ...

This to make sure the other images those depend on this will not broken.

[md5]

@edwardsamuel I agree with you in theory, but there are difficulties with doing this in practice. This was discussed in #8, particularly from this comment onward.

[md5]

Since I've been asked this question a few times, I'd like to elaborate what the difficulties are with maintaining multiple tags.

The main problem is that the postgis package, which contains the pgsql2shp, shp2pgsql, raster2pgsql, and shp2pgsql-gui userland binaries is not versioned with a release number in the name (e.g. postgis-2.3). This makes it so that Dockerfiles for old PostGIS versions will no longer build once a new version of PostGIS is released.

Since this image is linked in Docker Hub to the postgres image, any updates to postgres:9.6, etc will trigger builds of this image. If we were to have an mdillon/postgis:9.2-2.2 tag (for example), and a security release was made to the underlying postgres:9.2 image, we would not be able to build and updated mdillon/postgis:9.2-2.2 image due to the first issue I mentioned since the only postgis package at this point is the 2.3 package.

Another thing that makes me hesitant to have more specific tags is that Docker Hub doesn't gracefully support multiple tags for the same branch and Dockerfile. For example, if I want to have both "9.6", "9.6-2.3", and "latest" point to to 9.6-2.3/Dockerfile on master, then Docker Hub will build the same image three times instead of tagging a single build with three tags. This is mainly an efficiency issue, but since Docker Hub builds can be flaky it also means that one of those three builds could fail even though they are building the exact same image.

We could potentially work around the first and second issue by removing the postgis package from the image and only having the extension itself and related scripts (since those package have names like postgresql-9.6-postgis-2.3, etc). I'm not sure how many existing users that would impact since you generally wouldn't want to run those binaries from inside the same container as the server, but you could want to run them from a linked container using the same image.

The biggest problem with me maintaining multiple tags is that I have very limited time to maintain this image. I don't actually use the image myself anymore, so I'm mainly maintaining it to support the existing users since this seems to be one of the more popular "postgis" images on Docker Hub.

If Docker Hub supported renaming or redirecting existing images, I would be happy to transition this image to some sort of community maintenance, but as it is the image has to remain "mdillon/postgis" to avoid disrupting things for users (not to mention the fact that Docker's automated builds have been broken for this image ever since I renamed the GitHub repo from md5/docker-postgis to appropriate/docker-postgis more than a year ago).

[md5]

See previous discussion in #18 as well.