php@8.1 (currently) should not be an alias but a own recipe to avoid unexpected major PHP updates
AndreasA opened this issue · comments
Describe the feature
This is actually something that I already find quite annoying with the default brew PHP taps but it just doesn't make sense to have a brew upgrade switch PHP major versions, e.g. from 7.3 to 7.4 or even worse 7.4 to 8.0 or 8.1. If that PHP version is referenced If that PHP version is used this can create some issues, especially as 7.4 is basically uninstalled as it is replaced.
Therefore, I think it would be better to not make php@8.1 be an alias to php but a own recipe, that installs always 8.1 and also puts it into a 8.1 folder.
Then the php would probably need to be an own recipe that always installs the latest php. Not sure if an alias is enough here or a custom recipe that executes brew install php@ and then add a symlink from php to the php/8.1 folder. same for the configuration.
This way one can either select to always use the latest by installing php recipe or always have specific versions installed.
I would like to follow the same convention here as the core tap, otherwise, it creates confusion.
Also, I like the functionality to upgrade to the next major version using brew upgrade.
Please use brew pin to avoid upgrading.
https://docs.brew.sh/FAQ#how-do-i-stop-certain-formulae-from-being-updated
or better, install php@8.0 and switch to it, You can let brew upgrade the php formula, or you can remove it if you don't need it.
@shivammathur The problem is that if I install php@8.1 which I do, it actually install php.
This is why I said you should keep php as iti s now but make php@8.1 a separate recipe that doesn't automatically update. Brew is actually the only version that automatically updates to the next PHP version.
And I don't want to pin the version as I most likely will also want to use 8.2 later on, just not for existing projects. The point is that 8.1 would just be lost in this scenario (php is replaced with 8.2).
I also think that the brew implementation is wrong. Most package managers that provide multiple PHP versions use a fix version numbering.
On the other hand I agree to not differentiate from the brew version (too much) makes sense too.
Adding php@8.1 formula will require building PHP 8.1 twice, unfortunately, more burden on the already stressed CI system. There can be only 5 concurrent macOS builds in GitHub Actions per account for intel builds, and I only have one M1 machine for arm builds from macstadium.
On each library's minor version update in core tap, I have to rebuild each PHP version and that means close to 2 hrs of downtime, Unless someone sponsors extra CI machines for this, I do not want to add to this problem.
Thanks for the feedback. Yes. It makes sense to not do that then. Just thought it might be a good solution.
One thing that might be posslble - not sure how brew handles this - but apt often uses "meta" packages, that basically just require some other packages.
So e.g. the php package could just be a manifest that requires php@8.1 and then switch to php@8.2. That way if php@8.1 is installed, it stays at php@8.1 (even if the folders might switch) and if php is installed the newest version is automatically installed.
But I also understand if you do not want to go this route as it deviates from default brew PHP packages, just a suggestion and how I would prefer the PHP packages but your versions already help a lot as the PHP extensions are available via brew too and I don't need to reinstall previously wokring extensions with pecl because other libraries changes as well.