Hi, Jean, How granular it should be? Currently every frm stores the server version that created it. So if all tables in the mysql schema were created before the current server version - the downgrade is safe (with one exception). Except for mysql.global_priv - this one stores the version in every row, so if all rows are old, the downgrade is safe. I don't think there's any per storage data format version though. Neither in MyISAM or Aria nor in InnoDB. But let's assume they all store the version format. How would the server know the upgrade is safe? Checking all tables on startup is impractical. It can check the format version whenever the table is opened. This way compatible tables will work, incompatible tables will produce an error "Incompatible storage format". This is technically safe, but from the user point of view the application still doesn't work, so the downgrade can be hardly called successful. I think such a schema version and a storage format version will prevent crashes on downgrades, which is good. It won't solve user's problem of "downgrade and everything works" - this is likely impossible to do in a general case. On Aug 01, Jean Weisbuch via developers wrote:
Having an internal schema version that would be incremented only on internal tables schema changes (and not linked to major/minor versioning of MariaDB) in addition to per-storage data format versions would allow a relatively safe downgrade even between major versions if there has been no changes of internal schemas and of data format of the currently used storage plugins.
It would make it easy to block the execution of MariaDB only if one of the structure is newer than the server expects and it could be bypassed with a startup variable forcing the execution even if the schemas and/or data format might not be compatible.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org