What comes in between MariaDB now and MySQL 5.6?
We’re quite happy that we’ve released four major releases that are production ready (better known as generally available or GA in the MySQL world) in the last 26 months. That is just a little over two years, and a whole lot of features. In that same time, MySQL has seen one GA release (MySQL 5.5) and we’re all eagerly awaiting the upcoming MySQL 5.6.
You’ll note that we built MariaDB 5.1, 5.2, and 5.3 based on the MySQL 5.1 codebase. A significant number of features went into MariaDB 5.3 (our biggest GA release to date), with the biggest changes in the optimizer in over a decade. There were also many replication based changes included like the now famous group commit for the binary log. Our Knowledgebase has a summary of MariaDB 5.3 features.
Work on MariaDB 5.3 started long before MySQL 5.5 went GA. It was a huge task to move all these 5.3 features into MariaDB 5.5 and at the same time merge MariaDB 5.5 with MySQL 5.5. It caused a significant delay in us getting a release of MariaDB 5.5 out there as production ready software. By now it must be clear that we included all changes in MariaDB 5.5 from 5.3, 5.2, and 5.1. We spent the time developing new features and keeping it current against current versions of MySQL.
We released MariaDB 5.5 in April and we have always aimed for short release cycles where possible to keep up with rapidly changing distributions. With this in mind many have been thinking about the release cycle from now onwards.
What will the next release of MariaDB, which we are working on, be called? We want to release our new features in a GA version soon and not wait for MySQL 5.6 to reach GA quality. But if we release a GA version before MySQL 5.6 is GA, it will be very confusing to call our release 5.6. In addition, this time there are no free version numbers between 5.5 and 5.6 like there were between 5.1 and 5.5 when we could use 5.2 and 5.3.
We are thinking of calling it MariaDB 10.0. It will include stable GA-ready features from MySQL 5.6 (these will be backported), as well as encompass some of our plans for the next release. It will be based on the MySQL 5.5 codebase. Then we plan to release MariaDB 10.1, MariaDB 10.2 and so on.
What happens when MySQL 5.6 is GA-ready? We’ll release a MariaDB version 11.0. It will include all the features of MariaDB 10, and encompass the features from the MySQL 5.6 codebase (that weren’t already backported into MariaDB in a previous release).
Does this mean we are veering away from being a backward compatible branch to MySQL? Of course not. We will be feature complete. We’re just in the lull of time between MySQL releases, in a similar fashion to what we did for MariaDB 5.2 and MariaDB 5.3. Astute followers will note that there is no MySQL 5.2 and 5.3.
Essentially this is just a change in the numbering scheme. A change which allows us to release more often than MySQL does. You are invited to contribute to the conversation on the maria-discuss mailing list.
Comments
23 responses to “What comes in between MariaDB now and MySQL 5.6?”
Not following MySQL versioning numbers will cuase a total mess for ‘generic clients’ including GUI clients. Such clients will parse the version string to decide which features should be enabled in the client and which not. If you release MariaDB 10.0 based on MySQL 5.5 msot d´such client will assume that it has all fearures of 5.6 (as 10.0 is a larger number than 5.6 – simply!). It does not matter what you call it (marketingwise) of course – what matters is “SELECT VERSION();” returns
I suggest it should return “5.5.x – extended with MariaDB 10.x”
Of course as long as this is a single exception it can be handled in code (but old client versions without code for this exception will be confused) and if you first start this I bet it will grow only worse over time!
Thanks for the valuable feedback regarding SELECT VERSION();! It’s definitely something we will think of.
Thanks for this valuable feedback regarding SELECT VERSION();! It’s definitely something we will think of.
+1 on what Peter said. That and the need for more benchmarks! Those published by Percona and Oracle show that MariaDB may contain a lot of regressions, being faster than the other releases in some very limited cases only. It’s nice to optimize for borderline cases, but if the problems in other areas offset the gain…
Hi Bartek! More benchmarks are coming. Which Oracle benchmarks are you referring to?
Sorry, can’t find the Oracle ones – must have been thinking about “Oracle releases”. There is plenty of stuff that needs addressing, though (list below). I’m not saying these haven’t been taken care of but while problems do get pointed out, there is little public follow up from your end. With lack of information it’s difficult to weigh possible gains from optimizations with possible loss in regular workloads. It would be ideal if there was a set of benchmarks, both for regular workloads and MariaDB-specific, results of which would be available with *each* MariaDB release.
http://www.mysqlperformanceblog.com/2012/04/04/join-optimizations-in-mysql-5-6-and-mariadb-5-5/
Poor Join Optimizations performance under cold caches compared to MySQL 5.5
http://mysqlmaniac.com/2012/what-about-the-subqueries/
Poor subquery performance when subquery cache disabled.
http://www.mysqlperformanceblog.com/2012/02/18/mariadb-5-3-4-benchmarks/
Very poor sysbench performance.
https://mariadb.org/benchmarking-mariadb-5-3-4/
Poor performance vs. MySQL 5.1
http://www.mysqlperformanceblog.com/2012/03/21/multi-range-read-mrr-in-mysql-5-6-and-mariadb-5-5/
Poor multi-range read performance with in-memory workloads
http://blog.montyprogram.com/mariadb-5-3-optimizer-benchmark/
Random behaviour in query 11.
Hi,
I’m sorry, but I can’t see your point. Let me comment at your examples:
> http://www.mysqlperformanceblog.com/2012/04/04/join-optimizations-in-mysql-5-6-and-mariadb-5-5/
> Poor Join Optimizations performance under cold caches compared to MySQL 5.5
This is nothing I could ever reproduce. DBT3 is TPC-H. And for query #3 MariaDB 5.5 is 2-3 times faster than any MySQL version (just look at http://blog.montyprogram.com/mariadb-5-3-optimizer-benchmark/)
> http://mysqlmaniac.com/2012/what-about-the-subqueries/
> Poor subquery performance when subquery cache disabled.
That’s not what I read there. With subquery cache disabled, MariaDB is as slow as MySQL. And with this cache enabled, it’s faster. So what is your point again?
> http://www.mysqlperformanceblog.com/2012/02/18/mariadb-5-3-4-benchmarks/
> Very poor sysbench performance.
> http://blog.montyprogram.com/benchmarking-mariadb-5-3-4/
> Poor performance vs. MySQL 5.1
Those two posts must be seen as two sides of a medal. What Vadim tested was MySQL/InnoDB vs. MariaDB/XtraDB. And then indeed MySQL is faster. When you look at the second benchmark post, we compare with MariaDB/InnoDB and Percona Server too. And it turns out that all the bad benchmark results are for XtraDB – MariaDB/InnoDB is nearly as good as MySQL/InnoDB. It’s not MariaDB that doesn’t scale, it’s XtraDB.
> http://www.mysqlperformanceblog.com/2012/03/21/multi-range-read-mrr-in-mysql-5-6-and-mariadb-5-5/
> Poor multi-range read performance with in-memory workloads
Again a DBT3 query. This time #10. And again MariaDB was faster in all my benchmarks.
I should also mention that a comparison MySQL-5.6 vs. Maria-5.5 compares apples and pears. MariaDB-5.5 is GA while MySQL 5.6 is more a technology demo. As we have seen before, InnoDB vs. XtraDB makes a huge difference. MySQL-5.6 has got many improvements in InnoDB – something that MariaDB will inherit when it merges with MySQL-5.6 (but this won’t happen before MySQL-5.6 becomes GA). So we can certainly expect another performance boost for MariaDB after that.
Sorry but at this point you need to give up your own versioning and do it Percona style. If you want to release something based on MySQL 5.5 but newer than MariaDB 5.5, then call it 5.5-x.y. Anything else, like Peter notes, will create major incompatibilities with the real world. (Including users who will have no idea what you are doing.) Changing version numbers to not sync with MySQL only makes sense the day you completely depart from base MySQL and stop being fully compatible.
Thanks for your opinion! Peter already mentioned a solution to his worry in his entry. The versioning is like a balancing act where you have new development in MariaDB on one side and the underlying MySQL version on the other side.
Basically my proposal is the same, except without the text:
SELECT VERSION();
5.5.x-10.0
…if you want to call it version 10. I don’t care. Same version of course needs to be used for packages.
+1 for percona style versioning!
Actually I complained several times to MariaDB mailing lists when you released MariadDB 5.2. 🙂
If you want to avoid 5.4 you should also have avoided 5.2. There is/was a MySQL 5.2 release (it was continued as MySQL 6.0). MySQL 5.2 binaries and code are still available on FTP mirrors like ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.2/.
oops .. 5.4 is not relevant as we are discussing releases >= MySQL 5.5. Sorry and my mistake!
+1 for percona style versioning here as well. Just going to 10.0 willnto make sense. I could see a Ubuntu style versioning work as well, but only if you stick to a 6 month (or x-month) release cycle..
Name it version 9000 if it helps with marketing. What matters more is the planed behaviour with version specific syntax. i.e.
mysql> select /*!60000 1+ */ 1;
+—+
| 1 |
+—+
| 1 |
+—+
1 row in set (0.00 sec)
mysql> select /*!50000 1+ */ 1;
+——-+
| 1+ 1 |
+——-+
| 2 |
+——-+
1 row in set (0.00 sec)
I also think it should be a “mysql version string”-“mariadb version string” scheme as proposed by Peter, Henrik and others .
And what happens when MySQL switches to 10 in the far or near future? Why not multiply the version number by 10, so that there would, for example, be a MariaDB 56.1 . Sure, in the far, far future, MySQL will eventually reach version 56. MariaDB will then be at version 560, so that would be no problem, right?
[…] 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 […]
[…] up, MariaDB 10.0. In my late spring blog post about the next version of MariaDB, we informed you that the next version will be called MariaDB 10.0. There was a little storm of […]
[…] 我在今年春天的 博客中就提到了 MariaDB 的下一个版本将被称为 MariaDB 10.0。这个消息引来了很多的反馈，最集中的是这个版本变更的背后软件到底做了什么样的改变。我们仍然在总结这一点，但是可以明确的是 MariaDB 包含了一些 MySQL 没有的功能。所以我们要把版本号区分开来。还有几天我们就要发布 MariaDB 10.0 的 Alpha 版本了，我想要强调两个功能： – Multi-source Replication，很多人期待了很久的功能。你可以把你的数据分在很多个主数据库上，然后通过这个功能备份到一个从数据库上。这对分析数据是非常有用的。 – 获取运行中语句的查询计划（query plan）， SHOW EXPLAIN。到目前为止，在 MySQL 和 MariaDB 中，查询计划的打印并不始终正确。 […]
[…] entirely new features not found anywhere else. See “Explanation on MariaDB 10.0″ and “What comes in between MariaDB now and MySQL 5.6?” for more information on why we’re calling this series “MariaDB […]
[…] May of last year I blogged about MariaDB 10.0 for the first time. We received some feedback, digested it, and I further explained MariaDB 10.0. Now, with the first […]
Users of Oracle’s support services have no choice, as Oracle doesn’t support MariaDB, but otherwise a simple cost / benefit analysis and consideration of the likely future development of the two platforms probably favors MariaDB.