We do not specifically strive to support (the outdated and irrelevant) MySQL 5.2 of course. But we cannot prevent anyone from connecting to it with SQLyog. In that case SQLyog (any client) will have to assume that 5.2/6.0 functionalities are available (LOAD DATA XML, server side BACKUP/RESTORE .. to the extend that MySQL 6.0 features we implemented already - I did not check details).
.
Basically we do not support *specific* version. We work with any server the the compiled-in client (libmysql) can communitate with. If there is no server error or client error we simply open the program - porvided that we *can*. But acutally if there is uncertainity aboyt the meaning of the version string returned by by the server we may not even be able to paint the GUI (examples: 1) if we cannot identify clearly if version <5.1.0 we will not know if a database object can contain an EVENTS folder 2) what options should be in various menus depends on what server supports)
.
Also SQLyog is capable of connecting to an unlimited number of (different) servers simultaneously and will be able to copy and sync structure and data from one to another. For lots of those functionalities we will need to know details about server (fo isntance becasue code contains wrokaround for quite a lot of server bugs).
.
I do not claim that 5.2 mismatch is very important (MySQL 5.2 is dead). We will be able to work around ithis timet. I was more concerned about versioning going wildly different from MySQL in the future. So a very clear version string is requested so that we can code in 'knowledge about versions to the extent that SHOW and SELECT FROM I_S does not reveal information). It could be '5..1.88MDB_something ..'
.
btw: (I have critized Drizzle during UC for lack of discipline in versioning!)
On Mon, Aug 31, 2009 at 12:06, Henrik Ingo
<henrik.ingo@avoinelama.fi> wrote:
Hi Peter...
On Sun, Aug 30, 2009 at 5:47 PM, Peter Laursen<peter_laursen@webyog.com> wrote:
> I have a concern that I will ask you all to consider while there is
> time. I think I understand that after MariaDB 5.1 a 5.2 release is
> planned. I think it should not be versioned like that. Problem is that
> there is a MySQL 5.2 tree too (it is basically an early 6.0) and it is
> still available for download from FTP-mirrors like
> ftp://mirrors.dotsrc.org/mysql/Downloads/ .
And at Webyog you strive to actually support that version?
> For generic and GUI clients (ie. not designed for specific server
> versions and where SQL is generated and not written by user) it is
> important that the version string can be used to identify what SQL
> statements are supported by server. The first thing such clients (like
> our own SQLyog) does after connection is to SELECT VERSION() .. and only
> after that we know if there is support for EVENTS, if IF EXISTS is
> supported for DROP TRIGGER sysntax and so on. If there are two
> different 5.2 trees (MariaDB based on MySQL 5.1 and MySQL 5.2) it gets
> more difficult to handle.
> .
> I asked Monty about this at one of his sessions at the latest UC and he
> told like 'we are good citizens - except for the comment field MariaDB
> will be versioned like the MySQL code it is based upon'. What I also
> think is the best solution. The *version* should not be the same for
> different builds with even the slightest difference in what SQL server
> understands. On the opposite version should be the same as long as SQL-
> interface (even with possible Engine-specific extensions) is the same no
> matter how much they differ internally.
>
> Maybe in the long run diversification is inevitable. But in that case
> it should be planned well!
>From your point of view, how should we identify a release that
- Uses MySQL 5.1 as baseline
- Note: MariaDB 5.1 also uses MySQL 5.1 as baseline
- Has more features than MariaDB 5.1
?
henrik
--
email: henrik.ingo@avoinelama.fi
tel: +358-40-5697354
www: www.avoinelama.fi/~hingo
book: www.openlife.cc