Make php-8.1 minimum requirement
#4124
Conversation
* Rector: CQ - UnusedForeachValueToArrayKeysRector See Rector\CodeQuality\Rector\Foreach_\UnusedForeachValueToArrayKeysRector * fixes + phpstan See fix at rector: rectorphp/rector-src#6164
This reverts commit 3d7eaf6.
- updated workflows - phpstan baseline (will be fixed later)
php-8.,0 minimum requirementphp-8.0 minimum requirement
Co-authored-by: Ng Kiat Siong <kiatsiong.ng@gmail.com>
# Conflicts: # composer.lock # phpstan.dist.baseline.neon
php-8.0 minimum requirementphp-8.1 minimum requirement
|
Agreed with the changes, but I believe this should be in "next" so that it is in the next major version update.
Since v21 was not released yet this could still make it into v21. EDIT: Just saw there is already #3920 |
|
@colinmollenhour its on draft, b/c we should think about to raise minimum version for main branch too. |
# Conflicts: # .github/workflows/phpstan.yml # .github/workflows/sonar.yml # .github/workflows/syntax-php.yml # app/code/core/Mage/Media/Model/File/Image.php # composer.json # composer.lock # phpstan.dist.baseline.neon
|
Moving to php8.1 is no BC-breaking change. You only cant update 20,13 (?). v21/next contains breaking changes ... we cant use it as it is.
20, 21, 22? Why not continue with v20 to keep it simple? |
PHP8 has breaking changes and deprecations, so to me, it makes sense to have it in v21. It will reflect the major updates and ensure clarity for users and developers about the compatibility requirements. |
|
As a personal opinion, I would like to refer to OpenMage as one only version, with the possibility of releasing new versions periodicaly. I would use the project's front page or a pin to the discussions to prepare the community for major changes in advance, so that all those interested in upgrading can read about and take actions. For example, on date X the minimum PHP version will be 8.1, on date Y Prototype library will be removed from OpenMage. This v21/next would act more like a testing version until the new PRs are safe to be used in the main branch. All the changes that could generate BCs will be discussed in public then a deadline is set. Maybe there are people who want to sponsor some useful implementations and then those who implement them can be paid for their work. I have been using PHP 8.3 and 8.4 for some time now, both in production and testing. Regarding this PR, I would add it first to the next branch (for testing), setting a date for a new version of OpenMage (for example July 1st 2025), get ready a warning effective from today and attach a discussion section for it. If there are no differences of opinion, on the set date PHP 8.1 becomes the minimum PHP for OpenMage. |
What do you think about that?
|
Please check where the 42% came from. Its from users that run older OM-releases. Please see numbers for v20.11/20.12. And ... a lot of current PRs are about fixing php8 errors/deprecations. Not much other fixes. If you need php74, you only/mostly miss some updates for php8. |
|
Ref the medium article on PHP and release versioning. How about our own house rules: |
In all that years i cant remember to have agreed to any of that RFCs! Imho .... thats something for larger projects. |
|
Closed due to concerns. |
|
@sven, the Medium article you referenced makes a good case for it to be MINOR, one that I didn't think of before.. The fact that the composer package can prevent a user with the wrong PHP from upgrading is interesting - although in some cases I have used The purpose of the RFC is to make it clear to users what version specification it is safe for them to use given their updating practices. Given that we have ceased to support non-composer installations (we no longer build a zip file), I could see taking this approach if everyone agrees to allow PHP requirements to change in a MINOR version so long as they are specified correctly in the composer.json file. This would go against the Release Schedule guide, but if everyone wants it that way and there are no strong arguments against it, I would support this change to the release schedule document so it becomes official.
There were 11 votes Yea and 0 Nea after months of discussion, so not sure what to say to that... OpenMage/rfcs#10 Those are the rules currently, but it doesn't mean the rules can't change, just gotta make a proposal and get everyone onboard. |
I only said that i not agreed/participated. For me it is too much for a small project like this. |
My proposal was this PR. We have 72/27% out of 18 votes. For me it does not matter how the branch is called. We can bump the major version, but we cant use v21 b/c of breaking-changes ... |
|
Looks like OpenMage is broken on PHP 8.0 so it seems already in practice the minimum version is 8.1... 🤣 Given we have a currently "broken" build and the strong arguments for allowing PHP engine requirements to be a MINOR version change instead of MAJOR, I propose amending the Release Schedule and merging this PR. I'll follow up with a PR for the release schedule. |
|
Added PR to amend the release schedule document: OpenMage/rfcs#12 |
This should not happen, Can you confirm your |
|
I have one of the production servers on PHP7.4 running OM20.10.2. The composer lock entry: "require": {
"ext-dom": "*",
"ext-libxml": "*",
"php": "~7.3.0 || ~7.4.0 || ~8.0.0 || ~8.1.0 || ~8.2.0 || ~8.3.0 || ~8.4.0",
"sabberworm/php-css-parser": "^8.7.0",
"symfony/css-selector": "^4.4.23 || ^5.4.0 || ^6.0.0 || ^7.0.0"
},I have not encountered any issue. |
|
composer.lock should also have this "name": "symfony/css-selector",
"version": "v5.4.45",
"source": {
"type": "git",
"url": "https://github.com/symfony/css-selector.git",
"reference": "4f7f3c35fba88146b56d0025d20ace3f3901f097"
}, |
|
Ahh, maybe it's my mistake, then... I was trying to update the demo server and ran composer update, but maybe I ran it locally on a later PHP version than is used by the Nexcess server. Daniel updated the Nexcess config to use PHP 8.3 since then, so it's working now, but sounds like it would've been fine on PHP 8.0 had I run the composer update through Github actions. Oops... |
# Conflicts: # .github/workflows/phpunit.yml # .github/workflows/release.yml # composer.lock
|
I would go a little further by setting the minimum PHP version to 8.2 in 3 -4 months from now. I have been using this version for a long time in a test environment and all the problems that arose I reported and they were resolved. |
|
Yes, at this point 8.1 is EOL in just 9 months.. although if we're only doing minor versions for PHP upgrades, then it won't be so hard to update again later. |
|
|
There are currently several errors preventing the checks from passing... |
We removed 7.3 support in 03/2003 ... now - plus one year later - its time to make the next step.
PHP8 offers a lot of good features, i'd like to use when writing extension but i am limited due to php7 support.
Worth a read ... https://accesto.com/blog/php-performance-improvement-features/
According to packagist.org stats only 20% still use php7.4 with latest releases.
https://packagist.org/packages/openmage/magento-lts/php-stats#20.10
Note 1: If you have modules/extensions that dont work with php8, drop me a note! This should be no reason to stay on an old php version!
Note 2: OpenMage will still proberly work with older versions too - as long we not introduce backwards-incomaptible changes.
Note3 : with https://github.com/rectorphp/rector you have a tool to refactor your code for php8.