PHP Version Support Strategy

[ajbonner]

I just wanted to kick off a discussion about PHP version support, and I'm going to come at it from our own perspective but appreciate the project needs to accommodate different use cases.

Over the last week building Fedex Rest support I defaulted to our internal strategy of latest - 1, i.e. PHP 8.5 is current major release, so our code uses 8.4 compatible syntax. When 8.6 comes out, we start following 8.5.

OpenMage as of 20.16 sets a minimum supported version of 8.1, but that is now EOL since Jan 1 2026 so the Fedex code I'm working on (reasonably) has to support that...but it's limiting and frankly backward facing.

So I'd like to see more aggressive deprecation of older PHP versions, ie 20.17.x set 8.2 as a minimum.

Balanced against developer desires is the fact that merchants do not always have flexibility to update PHP according to the PHP EOL cycle. The drawback to the above then, is introducing code that can't run for these merchants. In theory the symfony polyfill libs should cover most of it, but there are language level features (think named arguments in php 8.0) that cannot always be handled.

So coming up with a strategy for this and documenting it, providing as much reasonable support for users/merchants would help set expectations and allow the codebase to modernise incrementally.

[sreichel]

So I'd like to see more aggressive deprecation of older PHP versions, ie 20.17.x set 8.2 as a minimum.

Short answer ... i'd like to require php83 in 20.18 or 20.19 release (approx 2-4 month?)

[ajbonner]

8.3 would be a good one to base on, gives you roughly 16 months of security cover before EOL and then 8.4 and 8.5 are pretty small jumps afterward. Gives the right balance of platform stability for dev + merchants.

This would effectively be trailing edge minimum PHP support which for a project of this complexity is probably about right.