How often should we increase our minimum PHP version
With new infrastructure on PHP 7.2 we've likely worked out all the kinks we are going to work out with PHP 7.2 so why not make it official?
Here are some hi-lights of stuff we'll get:
- Nullable types
- Short syntax for the list() function
- Class constant visibility
- Modern cryptography with libsodium
- Parameter type widening
Basically nullable types is nice and possibly parameter widening. Really though this is just to keep our codebase moving forward.
Comments
-
Just following up on this poll. The inability to use nullable type hints limits a lot of type hints I'm able to use in our external libraries. The fewer type hints I'm able to use the more potential bugs in our code or the more work I have to do to check types with code.
Sometimes upgrading a version requirement requires less net work.
0 -
I'm all for the move to PHP 7.2. PHP 7.0 is entering EOL at the first of December. PHP 7.1 is going away a year later. My only real concern of jumping from 7.0, which is our current documented requirement, straight to 7.2, is how it would impact the open source community.
A recent survey of sixteen of the most popular hosting providers found that 60% (10) of the hosts support PHP 7.2+, while 80% (13) supported PHP 7.1+. These aren't necessarily numbers that should hold us back, but I think they're worth considering.
Just following up on this poll. The inability to use nullable type hints limits a lot of type hints I'm able to use in our external libraries.
Nullable parameter types were introduced in PHP 7.1, so we wouldn't necessarily need to go straight to PHP 7.2. Actually, symmetric array destructuring and class constant visibility are also available in PHP 7.1. However, we would need to upgrade to PHP 7.2 for core libsodium support and parameter type widening.
All that said, I'm still onboard for upping our PHP requirements from 7.0 to 7.2. Since PHP 7.1 only has another year left in it, it seems shortsighted to only take the half step.
0 -
Here's my counterargument.
Currently PHP is using an annual release schedule and a 3-year support window (including security patches). That means, to stay inside support versions, you can at most upgrade 2 major versions at once (currently that'd be 7.0 to 7.2).
Therefore, if we drop support for versions significantly inside that window, we're basically saying "you need to migrate a major PHP version every year to use our software" because there would then be no way to stay on a major version longer than that (on average) and still use Vanilla. On a rolling basis, you have to use every single version of PHP, then.
As a sysadmin, telling me I need to mark my calendar to recompile PHP and QA all my shit every September sounds like a real bad time to me. Currently I'm doing it once every two years and that already feels murderous.
Even if you ignore the fact that a huge number of folks are still on 7.0 under the argument that forcing version upgrades is part of the role of end products like ours, it doesn't change my opinion that we should follow the PHP release cycle not preempt it because it's already a fairly narrow window for folks running the servers.
That would mean we drop 7.0 support after we're quite sure we're not doing further releases inside the support window.
0 -
For the record, offering a downside-free poll to devs is rather disingenuous. 😝 "Use your old car, or FREE NEW CAR?" Huh, weird outcome.
"Spend your entire Labor Day weekend upgrading PHP by carefully evaluating the upgrade path for your daisy chain of extension dependencies and doing QA on 3 applications using 15 years of legacy URL rewrites once a year OR every-other year" might get a different skew, eh?
0 -
And before anyone says "Yes of course you should upgrade every major PHP version" I will take this moment to point out that not even our own company did that. We stayed on 7.0 before jumping directly to 7.2.
Maybe we'll move to 7.3 incrementally this round, but that's not the facts on the ground currently.
1 -
I guess it's worth pointing out as well that there were numerous backwards incompatible changes in PHP 7.1 and PHP 7.2. We even ran into some ourselves.
But...
PHP 7.0 will no longer receive security patches after December 2018 http://php.net/supported-versions.php.
So I think come December there is no good reason for us to offer any support for PHP 7.0. Since that is not an option we have 3 choices:
Upgrade to PHP 7.1
We pretty much have to do this one and it seems to have the biggest improvements and the biggest breaking changes.
Major Features Gained
- Type safety improvements (This seems to be the biggest improvement). Nullable types, void functions, iterable pseudo type (This is huge in us trying to move it data fragments that are iterable classes. Improves type safety, helps us remove val in more places, improve memory usage).
- Class constant visibility.
- Syntax sugar for array destructuring.
Major breaking changes
- Throw on passing too few function arguments. This was significant. It required a good amount of effort on our part just to resolve issues with a single function call.
- The empty index operator is not supported for strings anymore. We also ran into this but its scope wasn't as large.
Upgrade to PHP 7.2
Whether we want this to me really depends on if we have any intention of using LibSodium or Argon2 any time soon. The rest of the stuff doesn't seem to be of significant utility.
Personally I feel like we could skip this one.
Major Features Gained
- LibSodium as a core library. Argon2 for password hashing. Are we actually intending to use this any time soon?
objecttype- Abstract method overriding and Parameter type widening. Does anyone else see a major benefit here? I almost view this as an anti-pattern because doing so breaks a contract of the base class.
Major breaking changes
I don't feel like listing all of these out. We didn't run into any of these issues however.
What about PHP 7.3
- heredoc improvements. These seem of limited utility as we are trying to never write templates in PHP going forward.
- Allow a trailing comma in function calls. This is a nicety.
- array_key_first(), array_key_last() I wasn't even aware that this was such a PITA in PHP, but I guess it is if want any accurate last/first index without affecting the internal array pointer.
- Enhancements to Argon2 password hashing.
Summary
If we want to support as many hosts for open source as possible:
Unless we want to use LibSodium or the more limited implementation of Argon2 password hashing in PHP 7.2 I think upping the requirement to PHP 7.1 and then jumping directly to PHP 7.3 next year.
If we don't care about the 20% gap in hosting that supports 7.1 and not 7.2
We jump to 7.2 and reconsider when 7.4/8.0 is out.
1 -
To get down to brass tacks and only worry about our immediate future: I'd like to upgrade to a minimum PHP 7.1 requirement after we fork for 2.8, which I assume will be sometime this winter. Whether it's slightly before or after the actual end of 7.0 support I don't really care.
0 -
I think we are ready to change 7.0 to 7.1 now?
0 -
Make an issue so that it can go into sprint planning. There are a few spots it gets updated in the code and documentation.
0 -
Notably here we have the Travis builds everywhere for some repos can drop the 7.0 builds. Then there’s documentation to update and probably the composer JSON packages. Yay nullable types!
0 -
Can we document the steps we need to do for the vanilla repo? There is always something we miss.
- Update the composer version requirement. Don’t forget to update the composer
built with variableconfig platform setting. - Increment the in app version check.
- Increment the readme version.
- Remove the old Travis build version.
- Check to see if we can update the PHPUnit requirement.
Anything else?
0 - Update the composer version requirement. Don’t forget to update the composer
-
I don't know what the built-with variable is, but I've transcribed and edited into an issue for our next sprint: https://github.com/vanilla/vanilla/issues/8368
0 -
It’s the config platform setting. It ensures that the composer.lock does not add a dependency that is too new when installed with a more recent version of php.
0
