首先， 我要著重詳述下為什么我們沒有把MySQL 5.6 直接拿過來作為二次開發的基礎，去做一個產品，可以唄稱為 MariaDB 5.6. 這個原因的細節我們直接都沒有和眾人分享。

1. MySQL5.6 的代碼庫的文件結構已經被改動了。比如單個代碼文件已經被分成多個，又或者是某些代碼已經被重新歸類到了不同的文件內。所以要把MariaDB 去配合現在這個文件結構一定是一個非常消耗時間的過程。而其實我確實不是很明白MySQL為什么要改動現有的文件結構。

2. MairaDB 5.5 已經有大量的代碼不同于MySQL 5.5 的版本，而且也有很多的新的特征被整合到MariaDB 5.5 中，而這些特征知道 5.6 版本 才出現在MySQL中。所以我們在比較同樣功能的MySQL 和MariaDB的版本，同時在完成設計和QA方面的審核后，一個很明顯的結論是MariaDB會是一個更好的產品。在大多數情況下，在選擇 MariaDB的時候，人們會更多的考慮到功能方面的偏好。

3. 所以MySQL的新代碼，至少是修改bug的代碼以后都沒有必要進行相應的測試了。我們試想一下，當有這樣一個功能要加入到一段代碼中，而這個功能原本就是來源于這段代碼的情況下，測試將是一個異常重要的過程來保證這個功能的正常運行。

和上文中提到的第二點和第三點一樣，Stewart Smith在Percona寫到關于Mysql最后安全補丁的回歸測試和QA如何測試使用MariaDB工程，以及保存在Percona服務器用作回歸測試的測試用例的重要性。參考： wrote yesterday about the latest security fix in MySQL introducing a regression

MariaDB不僅僅是Mysql的一個替代品。它的主要目的是創新和提高Mysql的技術，Mysql5.6不是一個合適的創新基礎平臺，所以我們就做了下面的事情：

1.由于我們引入了一些新功能（像? multi-source replication 多源復制, Cassandra integration , engine independent statistics 獨立統計系統等），所以我們需要搞個新版本。通常當你引入新功能時，你需要新建個版本。

2.下個版本稱作“MariaDB5.6”是不準確的，因為他不是基于Mysql5.6，取而代之，我們決定版本號調為10.0

3.MariaDB引入Mysql5.6作為一種替代方案的話，需要提升很多功能，我們已經邁出了第一步，正朝著合并或者重建Mysql5.6的功能方向發展。

首先，mariadb?10.0是一個主要數據庫版本，比如組合后的innodb與組合后性能架構，和一個新的全局執行事務id。夏日里，mariadb?10，有可能被當做GA開放式數據庫。(注釋)

通過階梯式的方法，我們的最終目的是聚合或者重新實現mysql5.6的所有功能特色。重新實現的所有功能特色都將同它們的mysql版本兼容。到此為 止，maria?10將全面兼容mysql5.6版本。除了頂部框架之外，其中含有眾多附加的mariadb數據庫的唯一的功能。

重 新實現功能的決定很簡單。如果從我們或者用戶的角度來看，MySQL 5.6缺乏該功能，那么我們就重新實現它。重新實現的決定并不是因為“我想這樣做”，或者受“非自主發明綜合征”的影響。每個問題都是經過認真而廣泛的討 論的。你可以加入郵件列表來參與這些討論，并且讓我們聽到你的聲音，郵件列表是? https://launchpad.net/~maria-developers 網站上的? maria-developers@lists.launchpad.net ?。

我們是不是有其他的選擇。答案是 Yes。我們本可以把最新版本的MySQL 5.6 拿過來作為MariaDB 5.6 的基礎，然后在其之上進行修修補補。但是，我們需要意識到的是：MariaDB 不是一個附加的補丁程序。雖然MairaDB 實在MySQL的基礎上建立起來的，但是我們有很多的工程師正在努力工作，他們的功勞是不可低估的。不得不提的是，我們全職的MariaDB 的工程師和QA人員一直在努力MySQL 技術可以更好地為MairaDB服務。

當然，還有另外一條路可以走，就是不再依賴于MySQL，并且不再兼容MySQL，如此，我們將稱為一個獨立的個體。但是我們不太采取這樣的方案。因為我們和眾多的MariaDB的用戶都收益于MySQL的功能，也很想MariaDB也同樣可以有這些特征。