Make php8.1 minimum requirement

[sreichel]

Long story short ...

• PHP8.0 is end-of-life since Nov 2022 (no security support since Nov 2023)
• more and more tools rely on php8.1+
• Magento2 requires php8.1 since 2.4.6 (Feb 2023)
• yeah, skip php 8.0

Just as we have abandoned support for PHP7.3, I would like to ....

• Make php7.2 minimum requirement #2402
• What do we miss for PHP8.1? #2253
• PHP 7.4 #3089

[sreichel]

Mhh ... not what i have expected. ❔

What are the resons to still want php7-support?

[Please] Letz moderize OM and dont rely on age old limitations.

[kiatng]

Is this for v20? I'm for supporting PHP7. No issue for v21 for min PHP8+.

[sreichel]

Why to support php7?

We dropped support for <7.4, why not do drop <8.1 - at the right time?

IMHO ... the right time is now.

I am a fan of backward-compatibilty, but changing the requirents to move forward isanother thing. Maybe I'd not have suggested this last year, but php7.4 and als php8.0 is EEOL for a long time now.

We are limitating ourself!

If you want to write an extension, you cant use php8 features as long you want to support latest OM-version, You also cant rely on other modern tools, that mostly require php8.1. THIS HURTS a lot.

I'd not suggest it, but you can still ignorephp-requirements during composer install.

[kiatng]

Would dropping support of PHP7 in v20 compliance with RFC Release Schedule?

[sreichel]

imho

Release schedule is not bound to any requirements.

(btw... we cannot use 21 as next major version ... skip and bump to v22?)

[JesperHerrloff]

Better to make 8.3 as Minimum requirement as 8.1 is End of Life later this year.

I migrated a client to OpenMage 20 from Php 5.6 Magento 1.9.1 Last Weekend.

I can probably help maintaining a bit of code as I am pretty familiar with the code base with all core hacks done to make the plattform work for a car spare parts dealer :)

I have not so much experience in working with other people on git so it would be a new experience.

[addison74]

In this survey I voted for yes. My opinion that at some date this year we should upgrade to version 8.2 as the minimum in OpenMage. Debian Trexie will come with PHP 8.4, I running intensive tests with OpenMage but not in production. So far there are no errors and those I found I reported already and most of them are fixed.

[addison74]

I wouldn't worry too much about the PHP version, I would rather focus on ZF-1 Future on which we base our project too.

[JesperHerrloff]

Even if a PHP version is EOL, there are particular situations when the operating system development teams offer support and security for a certain period of time. In Debian Bullseye 11 the version shipped is 7.4, in Bookworm 12 the version is 8.2. The former has an LTS until 2026.

I'm not saying we should wait until 2026, but I still believe that changes that create BC's should be notified in advance publicly and a time should be set when they are merged into the main branch. This time period can be mutually agreed by upon and represents a warning for developers to update their code. Obviously, a change must be tested for a while, for implementing this tasks we should have that PR in draft or something like not being merged before a date.

As a server admin you have to take some actions to keep software up to date.

A link on howto update to newer php in Debian Bullseye 11. There is often a way to solve most software updates.
https://www.linuxtuto.com/how-to-install-php-8-1-on-debian-11/

[JesperHerrloff]

I wouldn't worry too much about the PHP version, I would rather focus on ZF-1 Future on which we base our project too.

I completely agree with that. Will have to look into uses of the Zend Framework to see if its a viable solution to make some adapters to adapt to another framework.

[sreichel]

Zend usage .... openmage-strict#6

[sreichel]

Maybe add something like

• see Inform about php81/jquery371 Web_Notifications#7 ... ?

[addison74]

Web Notifications is a powerful tool to announce the users about these major changes. I will approve it right away.