Quoting: https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208358

• Add option '--check-if-upgrade-is-needed' to maria_upgrade the returns 0 or 1
  to the operating system (trough exit call) if a full maria_upgrade should be
  run.

• Now we only check if the last run was done with the same MariaDB version as
  last time. Change the check so that we check if the major version has changed
  (10.1.xxx -> 10.2.xxx). Change the error message from: default one: "This
  installation of MariaDB is already upgraded to 10.7.2-MariaDB, use --force if
  you still need to run mysql_upgrade" to "This installation of MariaDB is
  already upgraded to 10.7, use --force if you still need to run mysql_upgrade"

When coding this, take into account that there is a small change that we
in the future may need to run mysql_upgrade for a minor version. We
should have a function that check the version against a minor version
(by default current_major_version.99, like 10.6.99) and if the internal
version is smaller, then we still need to run upgrade.

• mysql_upgrade creates a 'mysql_upgrade_info' file in the data directory.
  When mysql_upgrade is started, take an advisory lock on the file
  (create it if it does not exists). This ensures we cannot have two
  mysql_upgrade run at the same time.

Future work:

• Find out why why running two mysql_upgrade in parllel causes lockups.
  If we can identify this and fix it, things will be much better as
  there is a chance that mysql_upgrade will now lock also for other cases
  than just another mysql_upgrade running.

• To make maria_upgrade faster, we should consider adding multiple thread
  support to mysql_check_table and run multiple check table & alter table in
  parallel. This should speed up mysql_upgrade for major version upgrades
  notable (in proportional to the number of CPU's in the system).