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.

Like others we were not satisfied with the fix for a bug in MySQL which caused the query cache and partitioning to not work reliably together. The bug, in simple terms, was that if the query cache was enabled and you used partitioned tables and if a partitioned table was using a transactional engine like InnoDB or XtraDB, the query cache could, under certain circumstances, return incorrect results.

Returning incorrect results is a definite, high-priority bug. However, the upstream fix was to disable all caching of queries from partitioned tables. We wanted a better solution because the query cache can be very useful and beneficial for partitioned tables, just like it is useful and beneficial for non-partitioned tables.

The root of the problem was that the query cache did not have any visibility into partitioned tables. In particular it didn’t know anything about a given table’s storage engine, including if the table was transactional or not. This lack of information prevented the query cache from intelligently caching and returning the cached results of queries.

We solved this by creating a way for the query cache to talk to the underlying storage engine of a partitioned table to see if it is:

  1. OK to cache the result of a query
  2. OK to return a cached result

With that information in hand the query cache can now properly cache new queries and provide correct cached results for duplicate queries every time, no matter if the table is partitioned (or not), or transactional (or not).

The patch is already in the MariaDB 5.5 source on Launchpad and will be in our next release of MariaDB 5.5.

Update: Monty has also written about this on his blog.

A screencast about the MariaDB release process.

MariaDB Screencast – The MariaDB Release Process
Watch this video on YouTube.

(I recommend watching it in full screen 720p, so you can see the details.)

Some links mentioned in the video: