Minor releases should get a new build/tag even they are no longer officially supported

[calvintam236]

These minor releases are mainly to fix security vulnerabilities. Although WordPress does not officially support these major versions (for new features), they are still being maintained if there are issues to security. (Similar to how Google releases security patches to Android after those devices will no longer receive a new Android version upgrade.)

Right now, NONE of these SECURITY minor releases are being released for the Docker community. Not every site can be directly upgraded to the latest WP major version due to plugin & theme compatibility issues on WP or PHP versions. (Consider production sites that cannot migrate to a new version until they are fully tested and approved.)

Note that those maintained versions should release w/ latest on the same EOL PHP major version (since WP did not drop support for PHP 5.6+ as of today). (e.g. PHP 5.6 -> PHP 7 is a major breaking upgrade, so PHP 5.6 should still be built with (for those minor releases on the maintained WP versions.)

Ref: #399 (comment)

[tianon]

Unfortunately, we cannot reasonably keep up with the number of versions that are actively updated by the WordPress project -- by my count from https://codex.wordpress.org/WordPress_Versions (looking at one recent security update from January 6, 2022), that would be more than 20 different versions of WordPress. That's why we opt to instead follow https://codex.wordpress.org/Supported_Versions, which explicitly states that only the latest release is actively supported and guaranteed to be maintained.

In general, you should have no problem using a newer version of this image with an older installation of WordPress (which will then also auto-update itself).

When I deploy this image, I usually use a very generic tag like wordpress:php7.3-apache so that I continue to get updates to the version of PHP / base image regardless of the version of WordPress installed/running (the initialization behavior only happens on the very first container startup); see also #689.

[calvintam236]

if you auto update WP core, it is losing the point of using Docker images with specific version tag. In production, we don’t want core auto updated without testing.

can the task automated? in general, it would be better to automate those using GH action when new version released on WP GH repo without actively maintaining old versions as long as the builds are successful.