-
Task
-
Resolution: Fixed
-
Blocker
-
4.3
-
MOODLE_403_STABLE
-
MOODLE_311_STABLE, MOODLE_39_STABLE, MOODLE_400_STABLE, MOODLE_401_STABLE, MOODLE_402_STABLE
-
MDL-76724_401 -
Since Moodle 3.5 (MDL-59159), these rules apply to decide Minimum PHP and Moodle versions supported:
- A LTS will always require the previous LTS (or later) for upgrading.
- The maximum PHP version supported for a branch will be the max one achieved along the life of the branch. Usually with .0 releases but may happen later (we added support for php70 with 3.0.1, or support for php73 with 3.6.4, for example).
- The minimum PHP version supported for a branch will be the lower of:
- The minimum version supported in any way by php the day of the Moodle release (so we provide slow, progressive increments).
- The maximum PHP version supported by the previous LTS branch (so we guarantee jumping between LTS is possible without upgrading PHP at the same time).
We need to decide ASAP about all the PHP/DB/Moodle versions requirements and put all them into the environmental tests (adding them to all supported branches).
All the still open linked issues have been also cloned here from the 4.2 sister issue (MDL-74905).
Usual discussions:
- PHP min. version/supported versions.
- database versions.
- Linked issues.
- ...
Feel free to propose areas to be discussed here. A numbered list with all them will be created to vote and decide the final outcomes of this issue.
 Related Tasks (create issues/PRs whenever they apply):
TODO-0: Recommendation. It's useful to look to the changes performed for previous versions, specially LTS ones, to see which sort of changes must be applied with this issue. Specially remember that any change to the minimum supported PHP always implies a change to the minimum upgradeable Moodle version (to the first one supporting the new PHP requirement).
TODO-1: (not needed) - Once the agreement is settled, if there are raised requirements (PHP/Database/Extensions...) create a MDLSITE issue to ensure that external testers environment is ready for them.
TODO-2: (not needed) - Once the agreement is settled, create a MDL issue about to guarantee that all the Community sites sites running the dev version fulfil the new requirements.
TODO-3: Once the agreement is settled, warn (apart from the previous points) about the agreed changes, listing them, so everybody is ready in advance for the upcoming changes. This includes:
- Integration exposed post.
- General dev chat.
- Internal dev chats.
TODO-4: (not needed) - Composer: To be done as part of this issue (master only):
- (not needed) - Raised lower PHP version does imply that core composer stuff need to be updated and regenerated with it.
- (not needed) - Also, check that all the php and extensions requirements and recommendations in the composer.json file match the ones specified in the admin/environment.xml file (defined by this issue).
TODO-5: Environment and upgrade: To be done as part of this issue:
- Add the new version section to the admin/environment.xml files, for all the supported (security included) branches. Ensure all the new requirements are applied.
- (not needed) - If Moodle requirements have changed, remove any upgrade step (and upgradelib functions) not used anymore (master only).
TODO-6: (not needed) - GHA integration: To be done as part of this issue (master only). Ensure requirements are fulfilled and there are jobs using the new versions.
TODO-7: (only 402_STABLE) - phpcs.xml.dist : To be done as part of this issue (master only). Ensure that the testVersion config setting matches the range of PHP supported versions. Note that for master branch we leave the range open always.
TODO-8: Once the agreement is settled, ensure that:
- The affected php docker images fulfill all the requirements (extensions...).
- Same for (still) non-dockered stuff, like:
- Legacy CI server. Ensure that bot master jobs and CiBoT runs are executed with minimum supported php version.
- Performance-comparison jobs.
TODO-9: (not needed) Once the patch is ready to peer-review, update all the configuration @ CI infrastructure:
- (not needed) Ensure (nightlyjobs) that every Moodle branch knows its lowest and highest PHP supported versions.
- (not needed) Verify that the runner (moodle-ci-runner) is using correct database versions.
- (not needed) Configure the following jobs if there is a PHP version bump:
TODO-10: (not needed) - Once applied upstream, changes are needed @ download.moodle.org to show the new requirements there (serverscripts).
TODO-11: (not needed) - Once applied upstream, ensure that both the Mac and Windows packages fulfill the requirements and work ok.
TODO-12: (not needed) - Once applied upstream, warn (apart from the previous points) about the imminent changes, listing them, so everybody is ready in advance for the upcoming changes. This includes:
- Integration exposed post.
- General dev chat.
- Internal dev chats.
TODO-13 (not needed) Once applied upstream, review the travis (only moodle-plugin-ci) and github actions configuration for various repositories. The new core requirements may be hitting them. Also add new branches if missing. Known to need review / fix repos include:
- moodle_docker (both own GHA and default php/db versions if raised)
- moodle-plugin-ci
- moodle-cs
- local_codechecker
- local_moodlecheck
- webservice_xmlrpc
- local_ci
- ...
TODO-14: Consider if there is any PHPUnit upgrade to perform whenever there are PHP version changes.
- PHPUnit 10 has been released, but we aren't in a hurry to upgrade. More yet, it only supports PHP 8.1 and up, so we cannot update to it until that PHP version is made a requirement for Moodle.
TODO-15: MDL-78496 - Ensure that the (clone of this) issue for next (to this) requirements issue is created and contains all the information. All the non-resolved details and issues must be dragged to the new issue.
TODO-16: Docs:
- (somehow related PR#668) - If there is any raise to PHP requirements, document it the PHP docs page (example PR).
- Ensure that all the requirements are shown in the corresponding docs (release and/or upgrade). Ask @ devdocs if the new version docs need to be created (example issue).
- (not needed) Ensure that there are landing pages @ docs for all the environmental changes performed.
TIA and ciao
Â
- has a clone
-
MDL-78496 Decide Moodle 4.4 requirements and push them to environment.xml (due date for voting: 2023-11-13)
- Closed
- has a non-specific relationship to
-
MDL-58615 Remove YUI CDN support
- Closed
-
MDL-60037 cachestore_memcached_test::test_multi_use_compatibility is failing again with memcached 1.5.0
- Closed
-
MDL-69684 It's possible to hold a redis session lock forever
- Closed
-
MDL-72359 32 Bit PHP autoconverts analysable::MAX_TIME (9999999999) to double
- Closed
-
MDL-73016 Prepare Moodle for PHP 8.1
- Closed
-
MDL-76405 Prepare Moodle for PHP 8.2
- Closed
-
MDL-76426 Prepare Moodle for PHP 8.3
- Closed
-
MDL-62640 Remove option to disable slash arguments (slashargs)
- Closed
-
MDL-76459 Expand Database Identifier Sizes (Column names, Table names)
- Closed
-
MDL-69960 Remove all the compatibility bits related with the end of IE11 support
- Open
-
MDLSITE-7069 Ensure that all the community sites are ready for the new Moodle 4.2 requirements
- Resolved
-
MDL-64482 Review not needed anymore PHP 5.x & 7.0 checks uses in core
- Closed
-
MDL-73587 Perform a complete PHPCompatibility 8.1 execution against codebase
- Closed
-
MDL-77458 Add phpcs testVersions to .phpcs.xml
- Closed
-
MDLSITE-6686 Verify testers VM supports Moodle 4.1 requirements
- Closed
-
MDLSITE-7055 Verify testers VM supports Moodle 4.2 requirements
- Closed
-
MDLSITE-7135 Remove Travis integration from Moodle core
- Closed
-
MDL-62352 Set default $CFG->forceclean to 1
- Open
- has been marked as being related by
-
MDL-77104 Perform a complete PHPCompatibility 8.2 execution against codebase
- Closed
- is a clone of
-
MDL-74905 Decide Moodle 4.2 requirements and push them to environment.xml (due date: 2022-12-26)
- Closed