Relax version check to ignore micro versions

[ChrisTX]

As is, imagick complains if the ImageMagick version mismatches even slightly. This means that while patches will not change the version, micro changes to the ImageMagick version will cause this. There's a discussion at Arch about this situation, considering it forces a rebuild of php-imagick on every single minor version change or it will print the warning message.

Yet, upstream declares that changes to the micro part of the version are backwards compatible:

3. MICRO version for added functionality in backwards compatible manner, and

For this reason, Arch carries a patch to disable the version check by default, as the constant new micro versions of ImageMagick do not interfere with the functionality yet require a rebuilt lest the warning is shown.

It's obviously not great to have to change this behaviour, and so I suggest this patch to relax the check: Instead of comparing the exact version, this checks if the imagickVersion is newer by less than a minor version, ignoring the micro part. php-imagick cannot immediately profit from newer functionality by a micro change, and there is no concern about backwards compatibility if the ImageMagick version is only newer by a micro version.

[Danack]

ImageMagick does not follow semver, which means:

there is no concern about backwards compatibility if the ImageMagick

version is only newer by a micro version. Unfortunately, yes there are. I mean, the small changes that happen in ImageMagick 'patch' versions, won't affect many users. But really whether a software package works or not being indeterminate is 'highly sub-optimal'.

considering it forces a rebuild of php-imagick on every single minor

version change or it will print the warning message. Doing a rebuild is the only way of making sure that nothing will break. I would pretty strongly recommend that people who want to distribute Imagick, package it with it's own version of ImageMagick, that is separate from a package of ImageMagick that is used for command line tools. While I am sympathetic to downstream software projects that package Imagick, I think that downstream projects need to solve downstream problems at the correct level, rather than pushing them 'upstream'. And yes, I really wish that I had influence upstream to ImageMagick, and could persuade them to follow semver with testing to prevent regressions. But I don't. Aaaaaaaaaaaargh, Dan Ack

…

On Wed, 23 Jul 2025 at 23:25, Christian Pfeiffer ***@***.***> wrote: As is, imagick complains if the ImageMagick version mismatches even slightly. This means that while patches will not change the version, micro changes to the ImageMagick version will cause this. There's a discussion at Arch <https://gitlab.archlinux.org/archlinux/packaging/packages/php-imagick/-/issues/3> about this situation, considering it forces a rebuild of php-imagick on every single minor version change or it will print the warning message. Yet, upstream <https://github.com/ImageMagick/ImageMagick/blob/main/m4/version.m4> declares that changes to the micro part of the version are backwards compatible: 3. MICRO version for added functionality in backwards compatible manner, and For this reason, Arch carries a patch <https://gitlab.archlinux.org/archlinux/packaging/packages/php-imagick/-/blob/main/php-imagick-3.7.0-skip_version_check_by_default.patch?ref_type=heads> to disable the version check by default, as the constant new micro versions of ImageMagick do not interfere with the functionality yet require a rebuilt lest the warning is shown. It's obviously not great to have to change this behaviour, and so I suggest this patch to relax the check: Instead of comparing the exact version, this checks if the imagickVersion is newer by less than a minor version, ignoring the micro part. php-imagick cannot immediately profit from newer functionality by a micro change, and there is no concern about backwards compatibility if the ImageMagick version is only newer by a micro version. ------------------------------ You can view, comment on, or merge this pull request online at: #739 Commit Summary - d658adb <d658adb> Relax version check File Changes (1 file <https://github.com/Imagick/imagick/pull/739/files>) - *M* imagick.c <https://github.com/Imagick/imagick/pull/739/files#diff-11a53ee3341a315920a8f582c11ce3b990fd929a1fdfb742474a8a09f65ee3eb> (2) Patch Links: - https://github.com/Imagick/imagick/pull/739.patch - https://github.com/Imagick/imagick/pull/739.diff — Reply to this email directly, view it on GitHub <#739>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALPTN2FNCBJCEKHCZBFNX33KADW3AVCNFSM6AAAAACCHEKLZWVHI2DSMVQWIX3LMV43ASLTON2WKOZTGI2TOOBYGIZTIMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ChrisTX]

ImageMagick does not follow semver

It was somewhat my understanding that the changed description introduced in version.m4 from 4 years ago had defined a meaning for the version number. Or rather, from what I have seen regards to ImageMagick handling this situation, they bump the minor version if the SOVERSION changes and in turn bump the SOVERSION if they add new library calls (e.g. here).
As of such, it was my understanding that compiling against two of the same micro version releases should yield identical binaries, bar the version string.

Doing a rebuild is the only way of making sure that nothing will break.

Due to what I just wrote, I don't understand how recompilation would prevent any issues if the ABI does not change. Regressions introduced in ImageMagick itself would not be resolved by doing so if they're in the library itself.

But of course, I'm writing this assuming the description cited is to be trusted. You would have much more experience with this subject than me or anyone downstream, and if you say experience has shown this versioning not to be trustworthy, then downstream will have to change their approach to packaging Imagick.

While I am sympathetic to downstream software projects that package
Imagick, I think that downstream projects need to solve downstream problems
at the correct level, rather than pushing them 'upstream'.

Absolutely, but as said, it was the understanding downstream that the SOVERSION and description in version.m4 are correctly applied, and that there should be no ABI changes between builds differing only by a micro version, making recompilation redundant - and thus the check itself too strict. But also, downstream should talk to upstream to ensure that no misunderstandings occur that cause issues for the end user (and unnecessary bug reports to an upstream project).

In this sense, the logic behind opening this PR was that either a) downstream's understanding was correct and then the check itself is not or b) downstream misunderstood why the strictness of that check was necessary, and then downstream needs to handle this differently.

I'd also like to point out that it's not just Arch patching the versioning check by default, but Debian (and thus Ubuntu) and Fedora do the exact same thing.

If this is indeed critical to leave intact, then this should probably be communicated more clearly, because as-is all major distros just disable the check, and having such a difference between upstream and downstream packages is not good for anyone.

[bukka]

I remember @remicollet also mentioned somewhere that ImageMagick sometime breaks ABI in patch version IIRC. Might be also good to get his thoughts on this.

[remicollet]

I remember @remicollet also mentioned somewhere that ImageMagick sometime breaks ABI in patch version IIRC. Might be also good to get his thoughts on this.

Yes IM is terrible at breaking things even in patch level (4th digit)

But when this happens, I report it and ask them to bump soname and bump to higher level ; at leat the 3rd digit (semver requires a 1st digit bump)

BTW in Fedora, we have imagick.skip_version_check=1 and we rely on soname change (as usually on Linux)

On each new IM version I'm used to run imagick build and test

• test suite using extension built with previous IM version
• test suite using extension built with new IM version

So this allow to detect early unexpected changes (ex: issue #737 ) in ABI (tests), API (build) and behavior.

When needed the repository provides packages built with the new version.

[ChrisTX]

But when this happens, I report it and ask them to bump soname and bump to higher level ; at leat the 3rd digit (semver requires a 1st digit bump)

It was my understanding from reading version.m4 that they bump the minor part of the version (alas, the 2nd digit) when they bump the SOVERSION, is that not correct? At least the bump from 9 -> 10 happened with the release of 7.1.0. Alas, 2nd digit bumps should definitely be rebuilt against.

But for the 3rd digit, from my understanding, an ABI change should only be possible if something slipped through and no SOVERSION bump took place - which should then be corrected anyway. And it would appear that all major distributions disable this check anyway and rely on the soname.

[remicollet]

For memory

• Jun 2021 libMagickCore soname bump to 10 in 7.0.11-14 (fixed by 7.1.0-0)
• Feb 2021 libMagickCore soname bump to 9 in 7.0.10-61
• Nov 2020 libMagickCore soname bump to 8 in 7.0.10-37
• Oct 2019 libMagickCore soname bump to 7 in 7.0.9-0
• May 2018 libMagickCore soname bump to 6 in 7.0.7-35
• Dec 2017 libMagickCore soname bump to 5 in 7.0.7-14
• Sep 2017 libMagickCore soname bump to 4 in 7.0.7-0
• Aug 2017 libMagickCore soname bump to 3 in 7.0.6-5
• Jan 2017 libMagickCore soname bump to 2 in 7.0.4-6
• Dec 2016 libMagickCore soname bump to 1in 7.0.3-9

[remicollet]

And it would appear that all major distributions disable this check anyway and rely on the soname.

Perhaps a simple way is to disable the check on Linux, as it is mostly there for Windows where there is no soname

See #740

[ChrisTX]

Oof, that's a mess. The definitions to version.m4 were only added in 2021, and from what I could find, the version change to 7.1.0 was made due to the soname bump. So maybe they intend to handle this differently nowadays?

Even for Windows, the check won't be all that useful if those breakages happen mostly during patch releases, I suppose?

[TharathielCB]

Push.

please merge this commit. I get this warning every hour since of a cron job for the Previewgenerator in nextcloud. Right now it is over 500 mails and notifications.

It is tedious.

Thank you very much.

[remicollet]

@TharathielCB simply set imagick.skip_version_check=1 in your php configuration.

[bukka]

I'm going to close this in favour of #740