version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in mater, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
Note this doesn't aim to be a complete change-set, but just the
minimum to switch to 3-digit $branches and keep installation, checks
and tests running and passing.
On installation (or also phpunit/behat unit) some CFG variables
were being used (on setting validation) before being set.
So this commit just verifies they are set before using them. Note that,
strictly speaking, only one of them ($CFG->searchenginequeryonly)
required the extra check, but I think it's better to apply it to all
them, as a reference and in case validations are run in any other order.
Currently, PHP getimagesize method doesn't support SVG images.
As some features, such as badges, processs and optimise the images
before using them, a new filetype group has been created to exclude
SVG from there: optimised_image.
SVG can't be removed from web_image because then users won't be
able to add SVG images to their courses using labels, pages...
Both ldap or the DB can return information in a non-consistent
ordering leading to events to be generated in different order.
And current tests are, right now, assuming a given order.
Note this is a rare random, but it's happening, so better
fix it, see the issue for some more details.
So we just do the tests ordering immune, verifying that all the
expected events have been triggered and done. Irrespectively of their order.
