Upgrade PHP to 8.3

[blackshadowshade]

I note that we're going to need to upgrade our infrastructure relatively soon (linking #2784 and #2928), so I'm opening this issue for the PHP part of that.

On #2784, I noted the steps we would need to take to migrate from 7.2-ish to 8.0.

[blackshadowshade]

Issues migrating from 7.2 to 8.0 (Copied from #2784):

• The ability to call non-static methods statically has been removed.
  • I don't think that we have any of these left, but if they're there, we should tidy them up anyway
• each() has been removed. foreach or ArrayIterator should be used instead.
  • I can't remember if we use each(), but it's possible.
• Inheritance errors due to incompatible method signatures (LSP violations) will now always generate a fatal error. Previously a warning was generated in some cases.
  • It's possible we have some of these in the daughter BMDie* and BMSkill* classes
• The precedence of the concatenation operator has changed relative to bitshifts and addition as well as subtraction.
  • I hope this doesn't affect us, but I'm not certain.

[blackshadowshade]

Potential issues migrating from 8.0 to 8.1 (from https://www.php.net/manual/en/migration81.incompatible.php):

MySQL Driver ¶

Integers and floats in result sets will now be returned using native PHP types instead of strings when using emulated prepared statements. This matches the behavior of native prepared statements. The previous behaviour can be restored by enabling the PDO::ATTR_STRINGIFY_FETCHES option.

[blackshadowshade]

Potential issues migrating from 8.1 to 8.2 (from https://www.php.net/manual/en/migration82.incompatible.php):

str_split() returns an empty array for an empty string now. Previously it returned an array with a single empty string entry. mb_str_split() is not affected by this change as it was already behaving like that.

[blackshadowshade]

Potential issues migrating from 8.2 to 8.3 (from https://www.php.net/manual/en/migration83.incompatible.php)

The range() function has had various changes:

If $step is a float that can be interpreted as an int, it is now done so.

[blackshadowshade]

Looks like the migration to PHP 8.3 should be pretty straightforward.

[cgolubi1]

I did some thinking about future things we might want to upgrade:

• https://endoflife.date/mysql
  • RDS seems to track "extended support"
  • looks like extended support is about 8 years, and maybe a new LTS version is released every 6 years, ish?
  • 8.0 LTS has EOL 2026-04-30
  • 8.4 LTS was released 2024-04-10, and as of 2024-07-17 is not yet in RDS
• https://endoflife.date/ubuntu
  • https://ubuntu.com/about/release-cycle
  • LTS releases give 5 years of security support for packages, plus various other optional things, but that's probably good enough for us
  • LTS releases are April of every even year
  • 16.04 was released 2016-04-21, and support ended 2021-04-01
  • so at this point we could upgrade to any of:
    • 20.04 - supported until 2025-04-02
    • 22.04 - supported until 2027-04-01
    • 24.04 - supported until 2029-04-25
• https://endoflife.date/php
  • seems like security support lasts for about 3 years
  • i think we install the ubuntu default version --- the last time we upgraded was alongside upgrading Ubuntu to 16.04 --- and i think we do that with good reason; a given Ubuntu version really only has first-class support for one PHP version.
  • the relevant current default versions are:
    • 16.04 -> 7.0 (EOL 2019-01-10)
    • 20.04 -> 7.4 (EOL 2022-11-28)
    • 22.04 -> 8.1 (EOL 2025-12-31)
    • 24.04 -> 8.3 (EOL 2027-12-31)

I want to come up with a proposed schedule, so we don't keep getting caught on the back foot by this. My suggestion is:

• We have one upgrade path for MySQL, and one for Ubuntu/PHP, and treat them totally independently. Based on my experience getting a different MySQL version installed on Ubuntu 16.04 just now, this shouldn't be a big deal, especially not if we're running less ancient OS versions.
• For each of those paths, start working on the upgrade 1 year before the EOL date.
• What that would look like for the next few upgrades:
  • ASAP (as soon as we feel up to it, anyway): upgrade to Ubuntu 24.04/PHP 8.3
  • 2025-04-30: start working on MySQL 8.0 -> MySQL 8.4
  • 2026-12-31: start working on Ubuntu 24.04/PHP 8.3 -> Ubuntu 26.04/PHP ?.?
• So, approximately one upgrade/18 months. That doesn't sound too bad.

[cgolubi1]

I discussed this schedule with Shadowshade offline, and we're going to go with it, and further get started on Ubuntu 24.04/PHP 8.3 in September, so that we can get it done soon, but have August to work on more direct player requests before pursuing yet another invisible infrastructure thing.

[blackshadowshade]

Linking Issue #3003, which talks about the changes needed to the test cases when we upgrade PHPUnit.

[cgolubi1]

Just noting: of course i didn't do anything on this task in 2025 (we both had limited BM time, and used it for tournaments).

I got notifications recently that RDS will end standard support for MySQL 8.0 on 2025-07-31. As we learned last time, they won't shut down our databases at that point, but they'll start charging extended support pricing, which is extremely punitive given how small our databases are (last time, the penalty was about 500% of our normal database cost).

So being on time for this upgrade is at the top of my priority list for the first half of this year. I'll start putting together a plan this weekend.