Single docker image for minor release

[sanak]

Supports #53

@cayetanobv @krashish8 (CC: @cvvergara, @smellman)

Changes proposed in this pull request:

• Single docker image for minor release (#53)
  • Even if version folder name doesn't have pgRouting patch version (ex. 15-3.3-3.4), this PR keeps to provide pgRouting patch version (ex. 15-3.3-3.4.1) ability as docker tag name by adding version.txt in the folder.
  • Fetch pgRouting latest patch version and store full version to version.txt in update.sh.
• Update update.sh with referring postgis/docker-postgis latest update.sh.
  • About fetching pgRouting latest patch version part, I referred docker-library/redmine update.sh (L18-L28, L33-L49).
  • Change master to main (pick from update.sh diff in #49).
• Remove libcgal (from https://github.com/pgRouting/docker-pgrouting/issues/52#issuecomment-1171341095).
• Update osm2pgrouting (pick from extra/Dockerfile.template diff in #49).
• Move existence patch version folders inside ./backup/. (commit diff:https://github.com/pgRouting/docker-pgrouting/pull/55/commits/d56301351e35345ebd15c00923097ed39a92d2c2)

• Create/update postgres=(11 12 13 14 15), postgis=(3.3) and pgrouting=(3.3 3.4 develop main) combinations

  • The main reason of postgres and postgis combinations come from the followings
  • PostgreSQL supports 11 - 15: https://www.postgresql.org/support/versioning/
  • docker-pgrouting only supports 3.3 in PostgreSQL 11 - 15: https://github.com/postgis/docker-postgis

  • Here is my local work memo:

    1. Create the following prepare-versions.sh file temporarily, then run it (bash prepare-version.sh).

       
       postgresVersions=(11 12 13 14 15)
       postgisVersions=(3.3)
       pgroutingVersions=(3.3 3.4 develop main)

    for postgres in "${postgresVersions[@]}"; do for postgis in "${postgisVersions[@]}"; do for pgrouting in "${pgroutingVersions[@]}"; do version="${postgres}-${postgis}-${pgrouting}" mkdir "${version}" touch "${version}/Dockerfile" done done done

    
    2. Run `make update`

• Update README.md to use new folder structure and version.txt and update example from latest tag version.
• Update Makefile to use version.txt and create alias (major.minor version) docker image.

I confirmed that make build generated all docker images without error in about 4 hours on my Ubuntu 22.04 amd64 desktop PC.

Confirmation point

1. Isn't it necessary to keep the past versions folders in ./backup folder ?
2. About pgRouting versions,
   • Is it enough to support recent 3.3 and 3.4 versions ?
   • Isn't it necessary to support develop branch, because it seems to be a bit out of date from main branch ?

---

Original (old) comment

Currently working PR for #53 I still haven't tested `make update` at all, so this is still my trial PR. About fetching latest patch version from pgRouting `major.minor` versions, I referred `docker-library/redmine` repository side, because `postgis/docker-postgis` side seems to depend on debian apt package release. https://github.com/docker-library/redmine/blob/master/update.sh --- - 2022/11/23: I will try minimum test at tomorrow. - 2022/11/25: I will add `version.txt` to store full version for docker tag name's version part (like `15-3.3-3.4.1` in `15-3.3-3.4` folder ,etc.)

[cayetanobv]

Can we close this PR #49 @krashish8 ? I think this was already solved here.

[krashish8]

Answering your queries (based on my own point of view):

Isn't it necessary to keep the past versions folders in ./backup folder?

I think it is not necessary to do that. We use git for the same purpose - anyone who wants to use these files can go back in history any time using git. If we are no longer maintaining these docker files, maybe we should not keep them. Anyway, there is no issue with keeping these files in the backup folder, so we are good for now.

Is it enough to support recent 3.3 and 3.4 versions?

I think yes, because the last release of 3.2 was last year, and we are no longer maintaining the older releases in pgrouting, aka no bug fixes. So, it is okay if we don't maintain the older releases docker container.

Isn't it necessary to support develop branch, because it seems to be a bit out of date from main branch?

Yes, I think we can support both main and develop branches - useful for those users who want to test the live "development" code but don't want to build from scratch - they can use the Dockerfile for main/develop to use the non-released code. I think this has been taken care of in this PR.

For questions 1 and 2 - I would also add that if we push Docker images in Dockerhub (or any such container library), it will contain the older releases, as normally we won't be deleting those, and anyone wanting to use them could pull them using Dockerhub. We won't be just maintaining the older Dockerfiles in this GitHub repo.

[krashish8]

Can we close this PR #49 @krashish8 ? I think this was already solved here.

Yes, @cayetanobv. I have closed that PR.

[cayetanobv]

Thanks for your review @krashish8 . I'm going to merge the PR

[sanak]

@cayetanobv Thanks for merging this PR! 🙇‍♂️

@krashish8 Thanks for answering my queries! I will create another PR which deletes ./backup folder, later.