maria-developers team mailing list archive

[Peter Laursen <peter_laursen@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxx>wrote:

> Peter Laursen <peter_laursen@xxxxxxxxxx> 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.
>