Whilst we have traditionally offered multiple versions of some of our images (PHP, Node.js, Solr, and Python), we have started to encounter situations where broadening the range of versions (and the images available with versioning) would be beneficial to our users.
The most notable examples here are:
- PostgreSQL (we’ve expanded our images available to include v12 alongside v11)
- Python (adding new Python 3.x releases)
- Redis (adding v6 alongside v5)
- Varnish (adding v6 alongside v5)
- MariaDB (adding 10.5 alongside 10.4)
As with our other images, we will follow the upstream EOL policies closely.
When we select whether to name images after a major version (i.e. Node.js 14) versus a minor version (i.e. PHP 7.4), we will look at the release frequency, semantic version policies, and the possibility for breaking changes.
We will also be able to generate pre-release images more easily – whilst they’re still in alpha/beta/RC status. Obviously, these images shouldn’t be used in production, but making them available for testing should be of benefit to us, our users, and the wider community.
This will allow our users to take advantage of the functionality available in the newer releases of these images. In order to configure this, the dockerfiles in your projects may need modification to point to the correct image for your purpose.
We have already written functionality into the release process to ensure that these new images are also published back to the existing images, under the same versions (i.e uselagoon/postgres-11:21.5.0 is the same image as uselagoon/postgres:21.5.0).
A complete list of these mappings is in the (makefile)[https://github.com/uselagoon/lagoon-images/blob/main/Makefile#L188]
Top comments (0)