Supporting continuity and open collaboration

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.


  1. Peter Laursen Peter Laursen

    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!

    • rasmus rasmus

      Thanks for the valuable feedback regarding SELECT VERSION();! It’s definitely something we will think of.

    • Rasmus Johansson Rasmus Johansson

      Thanks for this valuable feedback regarding SELECT VERSION();! It’s definitely something we will think of.

  2. Bartek Bednarowicz Bartek Bednarowicz

    +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…

  3. Henrik Ingo Henrik Ingo

    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.

    • Rasmus Johansson Rasmus Johansson

      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.

      • Henrik Ingo Henrik Ingo

        Basically my proposal is the same, except without the text:


        …if you want to call it version 10. I don’t care. Same version of course needs to be used for packages.

  4. Klaus Klaus

    +1 for percona style versioning!

  5. Peter Laursen Peter Laursen

    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

  6. Peter Laursen Peter Laursen

    oops .. 5.4 is not relevant as we are discussing releases >= MySQL 5.5. Sorry and my mistake!

  7. Walter Heck Walter Heck

    +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..

  8. 2012-05-28    

    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)

  9. Roland Bouman Roland Bouman

    I also think it should be a “mysql version string”-“mariadb version string” scheme as proposed by Peter, Henrik and others .

  10. cimnine cimnine

    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?

  11. 2018-07-25    

    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.

No Pings Yet

  1. Explanation on MariaDB 10.0 « The MariaDB Blog on 2012-08-13 at 11:09
  2. MariaDB Directions « The MariaDB Blog on 2012-09-28 at 06:37
  3. MariaDB 的发展方向 | 冰软 on 2012-10-17 at 22:53
  4. Announcing MariaDB 10.0.0 Alpha « The MariaDB Blog on 2012-11-13 at 01:41
  5. MariaDB 10.0 and MySQL 5.6 « The MariaDB Blog on 2013-01-14 at 18:50

Platinum Sponsors

MariaDB Foundation Platinum sponsors

Thank you,! Thank you, Alibaba Cloud! Thank you, Tencent Cloud! Thank you, Microsoft! Thank you, MariaDB Corporation!

Gold Sponsors

MariaDB Foundation Gold sponsors

Thank you, DBS! Thank you, Visma! Thank you, IBM! Thank you, Tencent Games!