- Screen-readers should not see 'clear my choice' when it is not visible
- 'clear my choice' option should only become visible when a choice is
selected
Under parallel development, when something is worth being commented
in upgrade.txt notes, it will be applied to all the development branches
using the "earliest" one to be released. So, if something changes
in 3.10 (and also is applied to master), the upgrade.txt notes will
show 3.10 in both branches.
Of course, if something only goes to one dev branch (say master), then the
master version will be used in the notes (4.0 in this case).
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 master, 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.
* Exporting via Oracle trims trailing zeroes in floating numbers which
results to a smaller file size for the exported file. Better to reduce
the minimum expected export file size from 4000 bytes to 3900 bytes.
That is, we don't call apply_attempt_state as soon as a
the data is loaded from the database. Instead, we wait
and only call it if really needed.
This should (especially after the next commit) be a performance win
during quizzes, particularly for people using advanced question
types liks STACK, or people making extensive use of the
'Try another question like this one' feature.
The gherkin-lint package now understands the use of "Examples" and
requries that their indentation be correct and consistent.
This change sets the indentatation for these to:
"Examples": 4,
"example": 6,
This is in-line with the examples given in the offical Cucumber/Gherkin
documentation at
https://cucumber.io/docs/gherkin/reference/#scenario-outline whereby the
Examples and individual rows of the Examples table are children of the
Scenario outline.
This is contrary to the default for Gherkin-lint which places them as
top-level nodes with an indentatio of 0, and 2 respectively.
