Specific PHP version tagging

[ciaranmcnulty]

It's unclear from the docker tags which PHP version I would be getting.

I think for adoption it'd be good to be specific about this, even if you only want to be building 8.2, make an :php-8.2 tag so that when you update to 8.3 people can stick on the older version

[jamogriff]

At least supporting 8.1 would be awesome. Minimum PHP version of 8.2 breaks PECL support during build: RUN pecl install xdebug: pecl/xdebug requires PHP (version >= 7.2.0, version <= 8.1.99), installed version is 8.2.0RC6

[withinboredom]

This is pretty normal for xdebug when a new version of PHP comes out. There is usually a compatible release within a few weeks of the PHP release. FWIW, if you use install-php-extensions xdebug inside the container, it will install the latest beta of xdebug which is compatible with 8.2. Here's a handy chart showing compatibility

[jamogriff]

@withinboredom Thanks for the added context. Now I'm good to go 🎉

That script you just linked to is a much better alternative than what the official PHP Dockerhub docs use.

[BeyerJC]

You can also specify a version or Branch when using extension Installer for example :

install-php-extensions xdebug-beta

[withinboredom]

I've been thinking about this problem for a bit and we've seen a couple of PR's try to tackle it. Right now, things are "simple" because there is only one PHP version to support, but things are possibly going to get complicated once 8.2.1, 8.2.2, 8.2.4, etc start getting released. The complication won't necessarily arise from PHP itself, but rather if there need to be changes to support a specific version.

It might be simplest to just manage a set of release branches. When 8.2.0 is released next week, we can create a branch in git: php-8.2.0, after some minor changes to CI, it will automatically build the following docker tags:

• :8
• :8-alpine
• :8.2
• :8.2-alpine
• :8.2.0
• :8.2.0-alpine

Once 8.2.1 comes out, we update CI again so that 8.2.0 only builds :8.2.0* and 8.2.1 builds the rest.

This gives us a few benefits:

• backporting new frankenphp features to older PHP versions is simply a cherry-pick or merge.
• we don't have to worry about breaking older PHP versions in main.
• users can easily have some stability by targeting these docker tags as they're unlikely to change much.
• Other software is released this way, so it should be familiar to anyone coming along.

Downsides:

• Merging from release branches to main is probably a bad idea. Development and bug-fixes should happen on main and then be merged back to the appropriate release branches. If a bug-fix only affects a single php version, development should happen in that release branch.
• It's a bit manual and needs documentation. However, this whole process should be scriptable and perhaps even be a github action itself, eventually.

Thoughts?

[dunglas]

Yo limit the maintenance burden, I suggest:

1. to support only the latest patch version of every minor
2. To ensure that the code is compatible with all minors using #ifdef macros

The main benefits is that we'll have only one branch to maintain and everything can be automated. WDYT?

[ciaranmcnulty]

I agree that single-branch is going to be easier (although that's not based on any internals knowledge)

If you continually publish each patch version you can just leave the old docker tags in-place as the project moves forwards

[RoadSigns]

To add to @withinboredom comment around the versioning.

Are we just thinking about PHP updates as well or will we also be including alpine updates as well since there is a big difference between alpine 3.16 and 3.17 for example so just having alpine could end up forcing people into downloading newer versions that could break their build?

So if versioning is being introduced the support for :8.2-alpine3.16 and :8.2-alpine3.17 might need to be introduced for people to feel comfortable using this in production without unexpected major version updates?

[back-2-95]

I somewhat touched the issue in #133

In bake definition file minor versions are easy to handle and distros also if wanna do different kind of tags for images.

Problem is patch versions like 8.2.1 etc. In our internal repo we use a script to find out current patch version from Alpine repos and then form this kind of command:

PHP80_MINOR=8.0.27 PHP81_MINOR=8.1.14 PHP82_MINOR=8.2.1 \
        docker buildx bake -f php/docker-bake.hcl --pull --no-cache --push

and docker-bake.hcl has those variables:

variable "PHP80_MINOR" {}
variable "PHP81_MINOR" {}
variable "PHP82_MINOR" {}

and they are used in tagging:

target "php-fpm-80" {
  inherits = ["common", "php-80", "php-fpm"]
  tags = ["${REPO_FPM}:8.0", "${REPO_FPM}:${PHP80_MINOR}"]
}

target "php-fpm-81" {
  inherits = ["common", "php-81", "php-fpm"]
  tags = ["${REPO_FPM}:8", "${REPO_FPM}:8.1", "${REPO_FPM}:${PHP81_MINOR}", "${REPO_FPM}:latest"]
}

target "php-fpm-82" {
  inherits = ["common", "php-82", "php-fpm"]
  tags = ["${REPO_FPM}:8.2", "${REPO_FPM}:${PHP82_MINOR}"]
}

[dunglas]

Closed by #163.