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.

On Friday last week, after the intensive days of the conference, Ars Technica wrote and published a nice article about MariaDB including many of the messages we had been delivering during the conference, http://arstechnica.com/business/news/2012/04/mysql-founders-latest-mariadb-release-takes-enterprise-features-open-source.ars.

MariaDB seals
MariaDB seals

Last year, when it became clear that O’Reilly wasn’t going to arrange the MySQL user conference in the future, there was a lot of discussion on who should arrange it. In the end Percona was pretty fast informing everyone that they had booked the convention center in Santa Clara to arrange the conference this year. Now with the results to hand it’s easy to say that the conference was very well arranged. Great work Percona!

The MariaDB booth was located in the .Org section of the expo hall and we experienced a huge crowd, especially on the first day (Wednesday) of the conference. Our t-shirts were really popular and we could probably have handed out even double the amount of what we had with us. Unfortunately for those in attendance, we had to put some aside for our next upcoming event in Bellingham, WA, USA 28-29th of April. It’s the LinuxFest Northwest 2012, http://linuxfestnorthwest.org. We hope to see some of you there!

We released MariaDB 5.5.23 GA on Tuesday of the conference. Apparently people just loved this news and we’ve enjoyed double our usual download rates since then.

On the SkySQL MariaDB Solutions Day on Friday the 13th, the MySQL founders Monty and David started the day with a panel and the day continued with sessions on all kinds of MariaDB and MySQL related topics. Make sure you read SkySQL’s summary, http://www.skysql.com/blogs/jenwilbur/seal-you-next-year-successful-mysql-friday-13th-santa-clara.
SkySQL has also posted pictures of the event on https://www.facebook.com/skysql.

Happy panelist Monty
Happy panelist Monty

During the conference we had many interesting conversations with people and businesses that we haven’t had a chance to meet before who had migrated to MariaDB. I’m certain there will be even more of these discussions this year and next.

To stay up to date with MariaDB, add yourself to the MariaDB announce list, which informs mainly about new releases. Also add yourself to the MariaDB Facebook page to get even more MariaDB news. Sign up at http://mariadb.org.

The MySQL community has something new on their radar. First up, it looks like MySQL is now part of Oracle Software Security Assurance, and this is something all MySQL users should be happy about. Next, it is worth noting that MySQL is now part of the Oracle Critical Patch Update (Oracle CPU), as the MySQL product line has made it into its first Oracle CPU advisory for January 2012.

As part of the MySQL community, CPU’s are new to us — they are released on the Tuesday closest to the 17th day of January, April, July and October. This kind of reminds us of Patch Tuesday, but let’s not digress.

This is the first time MySQL is part of the Critical Patch Update, and the advisory suggests that there are 27 new security fixes for Oracle MySQL, with one of the vulnerabilities having the possibility of remote exploitation without authentication. As developers of a MySQL branch we are naturally concerned towards the nature of these CPU’s.

For starters, it’s good to note that MariaDB is always based from a branch of MySQL (MySQL 5.1 for MariaDB 5.1, 5.2 & 5.3, and MySQL 5.5 for MariaDB 5.5). So whenever there are security fixes which Oracle makes into MySQL 5.1 or MySQL 5.5, we inherit them. This is one of the benefits of being a branch as opposed to being a fork.

“Oracle advisories include all issues that appeared since the last advisory. But this is the first advisory for MySQL. So either Oracle found 27 new problems since October 2011 or this includes everything that’s been outstanding,” said Sergei Golubchik, VP of Architecture for MariaDB and former MySQL security contact when I asked him about the 27 security fixes.

Upon looking up all the CVE numbers, the reports were vague, like “Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote attackers to affect availability via unknown vectors.” Additionally, the reports do not reference bug numbers, so from a bit of guesswork, we might assume that this commit is possibly the fix for the most serious vulnerability — the one that can be remotely exploited without authentication. That bug, incidentally, was fixed in May 2011, and has long been present in both MySQL and MariaDB (though our implementation varies from upstream).

We notice most CVEs being reported in January 2012, but have no idea when they were reported to the Oracle bug database (or to bugs.mysql.com), or when they were fixed. We believe that this is perhaps Oracle including MySQL into their Software Security Assurance program, which is what triggered all security bugs to be reported on cve.mitre.org, all on the same day.

Whether these 27 fixes are new or existing ones now being bundled up and reported in a Critical Patch Update remains open until more accurate information on what bugs they address is provided. We’re actively working on finding out the answer.