With the new release model supporting LTS (Long Term Support) releases, a given MySQL server will fall into one out of two categories: 

• Either, it is an LTS release.
• Or, it is an Innovation release. 

This blog post will explain how to determine whether a given MySQL server is an LTS release or not.

Defining release type

The MySQL server source code repository contains a file called MYSQL_VERSION defining the version number of the current release. We have added another field to this file called MYSQL_VERSION_MATURITY. Below is a sample file for an update release of 8.4.1, which is an LTS release: 

The new field is recognized by cmake, which defines a variable that can be used further in the cmake processing. Cmake also adds a definition which is recognized by the MySQL server source code. In the example above, we have defined the field MYSQL_VERSION_EXTRA to have the value "-u1". This is used only in cloud builds, and means that the release at hand is an update release of 8.4.0. Normally, for on-premise releases, the field is empty. 

Embedding LTS release type meta data

As part of the cmake processing, a file named INFO_SRC containing meta data about the source code is generated. This file is already part of the packaging and installation process, and can be read on a MySQL server host after installing the server. E.g. for RPMs, the file is located at: /usr/share/doc/mysql-cloud-server-8.4.0/INFO_SRC. Hence, the release type can be determined based on a server installation without even starting the MySQL server. Below is sample contents of the file INFO_SRC:

MySQL server upgrade history

In the past, the MySQL server used to generate a file called mysql_upgrade_info containing the version number of the last completed MySQL server upgrade. This file is deprecated, and is now removed. Instead, we now generate a file called mysql_upgrade_history. The file is generated when the server is initialized the first time. Then, for each successful upgrade, we will add an entry to this file, so it will contain a trace of the MySQL server versions that have accessed the data directory where the file is located. The file contains the timestamp of the upgrade, the full version string, and the release maturity type, structured as a JSON array. Please note that the full version string will include the MYSQL_VERSION_EXTRA field from the file MYSQL_VERSION, so the version string may contain more than just the version number. The first entry in the file, when the server is initialized, is also tagged with "initialize": true. Below is sample contents of the file mysql_upgrade_history:

Conclusion and further work

Both the INFO_SRC and the mysql_upgrade_history files can be read without having to start the MySQL server; hence, it is possible to determine the release type in a non-intrusive way. However, it might also be useful to determine the release type through an SQL statement against a running server. One possibility for supporting this is to add an information schema view, or a status variable, containing the same information as the mysql_upgrade_history file. Accessing this information through SQL is not yet supported, but might be something to consider in later releases.