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.

Agreed. We should aim to follow some specific conservative release. CentOS 7 seems reasonable.

+1 for CentOS 7.

We'll also need to have a policy re: PHP 8 soon, but there wasn't a lot of noise about it so maybe we're safe.

Isn't Centos End of Life soon?

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.

See https://secure.phabricator.com/T7408 and https://secure.phabricator.com/T13492 for latest info from the upstream (Minimum PHP version is currently 5.5).

Also, https://secure.phabricator.com/T7413 for the phone-home feature.

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.

In T15047#1302, @Ekubischta wrote:

Isn't Centos End of Life soon?

CentOS 8 is EOL soon, but CentOS 7 is/will be supported until 2024 iirc.

CentOS 7 ships with PHP 5.4 as a default, but there's PHP 7.x available via SCL (Software Collections).

and yes, I'm also running phabricator on top of CentOS 7 (using PHP 7.x via SCL).

There is no need to make a modern software compatible with PHP 5.x so I can agree to this change.

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:

https://we.phorge.it/book/contrib/article/php_coding_standards/

In T15047#3538, @valerio.bozzolan wrote:

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:

https://we.phorge.it/book/contrib/article/php_coding_standards/

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.

In T15047#3542, @avivey wrote:

I personally hate the $a = []; style, at least for empty arrays - I find it not-explicit enough.

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.

This is partially related:

T15158: "Modernize" codebase to features available since PHP 5.5 (that is the actual announced minimum)

I did some digging yesterday around PHP versions.

1. PHP < 8.0 is out of support according to https://www.php.net/supported-versions.php - no longer receiving security updates.
2. Debian bullseye+ and Ubuntu 20.04+ package manager ships PHP 7.4+
3. Debian buster and Ubuntu 18.04 package manager ships PHP 7.2
4. Red Hat 8+ have PHP 7.4+ available in shipped packages (Red Hat 7 does not ship any PHP it looks like)
5. Fedora project's EPEL registry has packages for 8.2
6. Rocky Linux appstream includes 7.4+

I'm inclined to actually implement this, partly because (AFAIK) nobody on the team is actually running on PHP 5 to check for problems.

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:

1. Update docs to say what is supported
2. Put up a blog post/something similar about it
3. (later) Make list of new feature we can use, decide which one we want
4. 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.

In T15047#1308, @speck wrote:

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.

Just tried to use diviner against some PHP files and it failed as xhpast couldn't cope with PHP 8 syntax.