As discussed on IRC / Matrix, it is probably sensible to raise the minimum required PHP version to 7.2. This will allow us, among other things, to better utilize PHP's type annotations and other new PHP 7 features.
- Mentioned In
- T15554: Handling PHP deprecations: convert to Setup Issues
D25142: Update Figlet implementation to be PHP8 compatible
Blog Post: Going Public
T15051: default.pem in Arcanist is out of date - maybe remove it completely?
- Mentioned Here
- T15158: "Modernize" codebase to features available since PHP 5.5 (that is the actual announced minimum)
T15145: Evaluate PHP Rector to quick refactor Phorge to support PHP 8.1 / 8.2 or do other things
I think our general strategy here should be focused around the versions of PHP available from the default/common package repositories for major server-based Linux distributions. There might be some situations where those package repositories only support very old versions (e.g. CentOS 7) which we should only plan to provide documentation for how to get the required version of PHP installed.
I'm mostly a Debian person (so I'm not aware of CentOS specifics) but my understanding is that CentOS 7 shipped with PHP 5.4 and has newer versions available via alternative repositories (not sure if official or not), while CentOS 8 (and Rocky Linux 8, if that matters) had PHP 7.2 by default and shipped a few years back. Is there a reason we're not basing our PHP support on latest distro releases (plus something like a year or two for a transition buffer), especially if newer PHP versions are available for older distro versions available as backports? I don't think requiring PHP / distro upgrades every few years is unreasonable.
The kind of teams that use Centos/Redhat are very conservative - they're exactly the teams that would not install PHP from an "alternative" source (or from source code). They also tend to keep to older OS versions, as long as they are supported, and would not be happy with a single machine being different from the rest.
All that to say, it would make these teams sad to require an upgrade.
As late as 2016, I was still personally using Centos 6, so I'm sure there's still Cenos 7 installs out there. Unfortunately, we don't really have any hard data - the only information we have is when people report issues.
Is it possible to pick a branching off point?
E.g. IF you cannot upgrade your PHP environment - You are welcome to use Phorge by checking out out commit xyz or branch xyz
Then - we can move forward, and leave a path for older installs to still function
Is it possible to pick a branching off point?
Yep I think this makes sense and is why I think our first release should still support PHP 5.4 but we can move off it after that.
I currently run Phabricator on CentOS 7 though I've updated to PHP 7.2 along with some other packages being upgraded past the standard/default package repository offerings (namely Mercurial).
At a certain point I think even if a common server distribution/version refuses to update past 5.4 it will still make sense for us to stop supporting but we should provide instructions on how to update PHP on those systems, like recommended alternate package repository or something -- hopefully there are official PHP instructions we could refer to.
In addition to supporting newer versions of PHP we should also determine how to handle XHPAST which I think is a home-grown linter/analyzer. We might need to make updates to it, or move off to other tooling if there is any.
Maybe unrelated. Can we - right now - update the coding standard to avoid $a = array() (that is a tremendous old approach) to just adopt $a = ? Note that the short version was introduced in PHP 5.4, that already is the minimum version right now. I'm talking about this document:
I personally hate the $a = ; style, at least for empty arrays - I find it not-explicit enough.
Granted, that's more about Python, where sets, lists and dicts all have short-hands, and the type of the object might not be clear at a glance.
OK no problem. To respect that, I tried to update the snippet in this experiment: T15145: Evaluate PHP Rector to quick refactor Phorge to support PHP 8.1 / 8.2 or do other things However, now I think I'm not going to work on that experiment for at least two weeks.
I did some digging yesterday around PHP versions.
- PHP < 8.0 is out of support according to https://www.php.net/supported-versions.php - no longer receiving security updates.
- Debian bullseye+ and Ubuntu 20.04+ package manager ships PHP 7.4+
- Debian buster and Ubuntu 18.04 package manager ships PHP 7.2
- Red Hat 8+ have PHP 7.4+ available in shipped packages (Red Hat 7 does not ship any PHP it looks like)
- Fedora project's EPEL registry has packages for 8.2
- Rocky Linux appstream includes 7.4+
Premising that I do not see the action plan here. What are the features that we are missing and we want to use, for example in the involved features and diffs?
For example, if "we" love array() instead of [ ] I wonder what we are missing
The primary feature is to immediately reject any support query for PHP 5.
There are other code features that are not available now (Some type-hints? Traits?), but I can't find a list right now.
In terms of "actionable steps" here:
- Update docs to say what is supported
- Put up a blog post/something similar about it
- (later) Make list of new feature we can use, decide which one we want
- Update linters to support new features.
Technically, (4) can be done already - the linters have support for "language version", and already support some features we can't use today (I think), possibly used in other projects online.