I do not have the perfect solution. The 'forking' means that different vendors will provide versions that add features. Before the forking started you could simply strip out the x.y.z information from SELECT VERSION().

A recnet MariaDB example Now MariaDB has 'virtual columns'. But how I tell except for trying to create such and get an error? Just a loose idea: implement SHOW EXTRA_FEATURES? This would then list all features in 'forks' that the parallel MySQL/Oracle version has not. Then the client/user would know what is possible to do and what is not without resorting to try-and-error method.

Two more simple examples: 1) There is no 'have_events' variables. A client or user will need to know that EVENTS are available in 5.1+. If somebody would release a 'fork' named 5.1.x with´out EVENTS it would be a mess. 2) There is no way to tell if server supports LOAD DATA XML except that this is known to be available in 5.5+

(and an old complaint of mine: there is no way to tell if a storage engine supports FOREIGN KEYS. Even SHOW ENGINES/SELECT FROM I_S.ENGINES does not expose this for each engine installed. The client/user will need to know that this is available in InnoDB/ExtraDB and PBXT (and the discontinued SolidDB). We have to hardcode in SQLyog that if - and only if -engine is InnoDB | PBXT | SolidDB we enable GUI functionalities to handle FK's. But there are so many enginess now that we cannot know them all. There could be (or soon come) more with FK -support). Also in MONyog we would like add supportt for 'fork' features (IS plugins - like the user statistics plugin - for instance). But if a user uses MONyog to monitor 200 servers where 80% are official MySQL/Oracle version and the rest a mix of various forks (MariaDB, PerconaServer, OurDelta etc.) it becomes a little complicated to manage what to do and not to do for each server. It was easier in the old days where x.y.z information from SELECT VERSION() provided all information. But now 5.2.z can be both MySQL 5.2 (that was later named 6.0) and MariaDB 5.2. This is not a big deal as MySQL 5.2 is probably not used at all. It would be a bigger deal if mariaDB 5.6 is released based on MySQL 5.5 codebase and MySQL 5.6 introduces new major features that MariaDB 5.6 has not. But I don't know what exactly is planned for MySQL 5.6 - however it is out now (refer ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.6/ and http://dev.mysql.com/doc/refman/5.6/en/

Rohit will be at the UC. I cannot tell if he will be able to join the above-mentioned MariaDB event and how much. He also is part of some SkySQL event as a speaker/panel member. I will ask him to discuss this concern where and with whom he thinks appropriate. I do not think we can expect Oracle to be mcuh concerned about this problematic. But I think the vendors providing forks should - and I belive it would be in the interest of all majorn vendors providing forks to agree on a uniform solution.

.. Peter

On Sat, Apr 9, 2011 at 17:10, Kristian Nielsen knielsen@knielsen-hq.orgwrote:

Peter Laursen peter_laursen@webyog.com writes:

...

I noticed this on planet.mysql: http://kb.askmonty.org/v/plans-for-56

I *again* strongly want to discourage a major version number identical

with

...

a MySQL/Oracle release. MySQL plans a 5.6 too and I believe that there

is

...

already a source-tree available on launchpad. I think I understand that MariaDB 5.6 is planned to use MySQL 5.5 codebase. Am I correct?

I don't think we would use 5.6 for MariaDB based on MySQL 5.5 (as opposed to MySQL 5.6) codebase. That would be confusing indeed.

MariaDB 5.6 would be a version that included MySQL 5.6. If we need to release what we now call "5.6" before MySQL 5.6 is released/stable, I think we would need to come up something else...

Similarly, the next release of MariaDB will be called 5.5 or 5.3, depending on whether we decide to include MySQL MySQL 5.5 or not.

...

I have now posted this complaint 2 or 3 times (including the times I complained about the use of 5.2 for a mariaDB based on MySQL 5.1 code as there is alose a (now abandoned) MySQL 5.2 tree. I never had a reply

from a

...

MariaDB 'decisionmaker'. Could I at least request a reply this time? Please! :-)

I also do not think current version schema is perfect. However, do you have a better suggestion?

The good thing about MariaDB 5.1, 5.2, 5.3, 5.5, 5.6, ... is that given MariaDB X and MySQL Y, you can know that MariaDB X includes all of MySQL Y (and thus can be used as a drop-in replacement) as long as X >= Y.

Can we do something better that solves your concerns, and still preserves this nice property in some way?

- Kristian.

"Adam M. Dutko" dutko.adam@gmail.com writes:

Does the following item under the Performance section indicate optimizations for AMD chips are not being added?

Better multi CPU performance above 16 cores (Work with Intel)

No (very unlikely).

The AMD and Intel x86_64 chips are quite similar, and most optimisations will help either, certainly optimisations aimed at scaling to many cores.

The "Work with Intel" probably refers to the fact that Intel is helping the work by donating many-core servers to MariaDB developers, and maybe with advice/discussions.

- Kristian.