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.
I don’t think your argument really makes sense – since as long as MariaDB is the superset of features, what tends to matter for tooling is getting a base-line (aka the MySQL release MariaDB is based on). If it’s not SELECT VERSION(), will there be an easy way to identify the MySQL release that my MariaDB server is based on?
MariaDB is not just a superset of features. From the post: “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.”
That only doesn’t make sense if you call it MariaDB 5.6.1 when it’s not based on MySQL 5.6.1.
Maybe it’s a different situation for others, but most of the official MySQL 5.6 features are more valuable to me than MariaDB changes. If I can’t trust that I have exactly what I had with MySQL + another tablespoon on top from MariaDB – but you may take something away… then you create obstacles for my adoption.
It’s all about the baseline.
Right. We are adding official MySQL 5.6 features to MariaDB. But we won’t be adding them in the order in which they were added to MySQL. That’s why next MariaDB releases will have MySQL 5.6 features. But MariaDB will be, strictly speaking, only a superset of MySQL 5.5 until we add *all* features of MySQL 5.6.1. And having ported 5.6.4 and 5.6.5 features, it will be confusing to continue calling the release MariaDB-5.5.
This is the reason for using a completely different version number.
This breaks the /*!56 */ comment syntax that allows for version-dependent parsing. That is, the syntax inside the comment is executed if the version number is *greater* than the given version.
But there is a solution to this: just make the MariaDB version numbers negative, and increasing in the negative direction! 😉
Yes. But there is no versioning scheme that will make /*!50601 */ comments to work, because MariaDB both has some newest MySQL features, from new MySQL versions and misses older features that were added to MySQL chronologically before these new features.
And this is exactly why MariaDB has extended this comment syntax to support /*M!50301 */ – this was implemented more than a year ago.
Details of MariaDB’s extended comment syntax are here: http://kb.askmonty.org/en/comment-syntax/
For the foreseeable future MariaDB will be an alternative to MySQL, not a first-class replacement. I know it grates, but then again look at how Internet Explorer reports itself to web browsers:
“Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.40607)”
or
“Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)”
even though Netscape has not been the leading browser in over a decade.
I would recommend you create a new function MARIADB_VERSION() for MariaDB-aware tools, and keep showing the baseline version of MySQL you fully support in VERSION(), e.g. ‘5.5.25-MariaDB 10.0 partial 5.6.1’
Please rethink this. I have nothing to add besides what’s already said in the comments above, but fully agree with them.
I get why this was done, basically to distinguish it from MySQL, but there should probably be something in the “releases” page that explains this to people like me who were not using MariaDB when the Big Skip took place. I look at it now and see work in the 5.5 series as late as the end of July, and in the 10.0 branch as late as mid-August… to someone coming from MySQL, this looks like some kind of much nastier split, similar to Python 2 vs. 3 (which I’m glad is finally ending). I spent hours on this website and Google trying to figure out what the heck was going on here. Just sayin’. 🙂