Explanation on MariaDB 10.0

In end of May I told about the numbering plans for the next version of MariaDB in the blog post What comes in between MariaDB now and MySQL 5.6?. We received quite a lot of feedback and criticism on the idea of calling the next version MariaDB 10.0. Here is a little more information about why it makes sense to call the next version 10.0.

This is not news for most of you. MariaDB is not just a set of patches applied on top of MySQL. MariaDB includes features which are similar to the corresponding features in MySQL, but the implementations differ, like for example the thread pool, microsecond support and query annotations in RBR binlog. MariaDB also includes a lot of features that are not in MySQL. For a complete listing of feature differences check out http://kb.askmonty.org/en/mariadb-versus-mysql-features/.

To call the next MariaDB version MariaDB 5.6 would be misleading.

Eventually there will be a version of MariaDB which includes all the features of MySQL 5.6 either ported or implemented in a different way, but before that there will be at least a couple of releases which include some features which have been ported from MySQL 5.6 and some completely new features that aren’t in MySQL 5.6.

A concern we have received is that tools and other clients validating the server version they are connecting to might become incompatible with MariaDB without changes in the tool/client. Thank you Peter Laursen from Webyog for your input on this! The issue is that tools and other clients rely on the return statement of “SELECT VERSION();”. Based on what version number is returned the tool enables / disables features. The fact is that no version numbering can solve it. Even if we would call our next release 5.6.1, it would not have all the features of MySQL 5.6.1, only some of them. It would also have some of the features of later MySQL releases, and features that are not in MySQL at all. In other words no single MySQL version number can adequately describe the feature set  of MariaDB. Thus we think it will be less confusing and less ambiguous to use a completely different number, a distinct version series.

We suggest that “SELECT VERSION();” return the correct version, e.g. 10.0.1-MariaDB.

In addition to the reasoning above current MariaDB releases already introduce additional functionality for tools — like more statistics and extra switches — compared to MySQL. This added functionality is highly beneficial for tools to take advantage of. We highly recommend tool vendors to separate between MySQL and MariaDB in this regard today, and doing so will only become more important going forward. We are also thinking about introducing a way for DBAs to impact what the VERSION() string says.

One area that seems to rule out all fancier version numbering, like 5.5-10.0, is the distribution packages, which in general support only normal versioning of type major.minor[.build[.revision]]. Even if a specific package format would support some more complex version number scheme the upgrade determination becomes hard if the introduced new version number is not only incremented numbers.

I hope this explains the logic behind choosing 10 to be the version number of the next MariaDB version. Your feedback on this is still however still more than welcome.