Bug #47420 | information_schema.plugins.PLUGIN_VERSION doesn't specify the full version | ||
---|---|---|---|
Submitted: | 17 Sep 2009 18:34 | Modified: | 17 Nov 2009 3:41 |
Reporter: | Mark Callaghan | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Information schema | Severity: | S3 (Non-critical) |
Version: | 5.1.38 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | information, innodb, plugin, schema |
[17 Sep 2009 18:34]
Mark Callaghan
[18 Sep 2009 17:13]
Vasil Dimov
Mark, the problem is that MySQL only allows one dot to be displayed in information_schema.plugins.PLUGIN_VERSION. Thus we decided to display only the first 2 numbers from the version because anything else would be confusing or hard to interpret. 1.04 isn't good because how would you display 1.0.10? 1.1.0? From the commit log message at the time I added the version: --- cut --- Add InnoDB version in these places: * In INFORMATION_SCHEMA.PLUGINS.PLUGIN_VERSION, only 1.2 out of 1.2.3 because MySQL supports only one dot there * At startup: "080501 12:28:06 InnoDB Plugin 1.0.1 started; log sequence number 46509" * In a server variable innodb_version; mysql> select @@innodb_version; +------------------+ | @@innodb_version | +------------------+ | 1.0.1 | +------------------+ --- cut --- from univ.i: --- cut --- /* The following is the InnoDB version as shown in SELECT plugin_version FROM information_schema.plugins; calculated in make_version_string() in sql/sql_show.cc like this: "version >> 8" . "version & 0xff" because the version is shown with only one dot, we skip the last component, i.e. we show M.N.P as M.N */ #define INNODB_VERSION_SHORT \ (INNODB_VERSION_MAJOR << 8 | INNODB_VERSION_MINOR) --- cut --- There is a way to craft something like 1.2.3 -> 102.3 but that would be confusing, this is why I added the innodb_version variable.
[18 Sep 2009 17:14]
Vasil Dimov
P.S. now I realize 1.04 is not possible, see the comment from univ.i
[18 Sep 2009 17:17]
Vasil Dimov
Setting to "Won't fix" - there is a way to get the InnoDB Plugin version and it is not possible to put the string "1.0.4" in the I_S table.
[18 Sep 2009 17:29]
Mark Callaghan
This should be fixed and it already causes confusion. For example, when filing a bug at support.mysql.com for the InnoDB plugin, the UI asks for the value of PLUGIN_VERSION to identify Innodb. Given the Innodb version numbering schema that will be a constant for every major MySQL release. If this isn't fixed in InnoDB, then it should be fixed in generic MySQL code. Why does it restrict version numbers in PLUGIN_VERSION to A.B given that MySQL and InnoDB use A.B.C as release numbers?
[18 Sep 2009 18:08]
Vasil Dimov
Mark, setting back to "Analyzing". We can either: 1. Go for 102.3 2. Ask MySQL to support an arbitrary string 3. Ask MySQL to support two dots instead of one. It would be something like: if (ver >> 16) > 0, then "ver >> 16" . "ver >> 8 & 0xFF" . "ver && 0xFF" else use the current "ver >> 8" . "ver & 0xFF" to preserve compatibility 4. Still do nothing, don't fix
[18 Sep 2009 19:38]
Davi Arnaut
5. 104.0 (as PLUGIN_TYPE_VERSION)
[19 Sep 2009 0:02]
Mikhail Izioumtchenko
still, 1.1.0 vs 1.0.10. The solution could be similar to what I believe modern rpm system uses: 1. assign N decimal places to each part of the 1.6.66 notation. N should be big enough to accommodate whatever we plan to release , 2 for 1.0.99, 3 if we are thinking about 1.0.327. 2. let's say it's 2. Then 1.6.66 is converted to 010666. 3. optionally leading zeroes are dropped and a dot is inserted in an arbitrary location: 1.0666 no, matter 1.0.4 is vastly superior to 1.0004
[21 Sep 2009 5:15]
Vasil Dimov
Michael, it is not possible to have leading 0s after the dot. E.g. 1.0004 is not possible. Yes, there are ways to accommodate MM.NN.PP (or MMM.NNN.PPP) into XXXXXXXXXX.Y, but they would be illogical and/or confusing. This cosmetic thing is starting to gather too much attention.
[15 Feb 2011 7:30]
Sergey Vojtovich
There is a whole variety of software versioning conventions: http://en.wikipedia.org/wiki/Software_versioning I read manual regarding plugin version and see: <quot> The plugin version number. When the plugin is installed, this value can be retrieved from the INFORMATION_SCHEMA.PLUGINS table. The value includes major and minor numbers. If you write the value as a hex constant, the format is 0xMMNN, where MM and NN are the major and minor numbers, respectively. For example, 0x0302 represents version 3.2. </quot> I read review comments for the patch that added <quot> Ok to push after fixing it (after removing st_plugin->version, removing version check from handler.cc, and correcting make_version_string()). </quot> All of the above makes me think: - st_mysql_plugin::version is not generic and cannot be generic as such; - the only purpose it serves is confusing PLUGIN_VERSION in I_S.PLUGINS; - it was added mistakenly, without any proper design and idea behind it; - those plugins that want to expose version should use st_mysql_plugin::descr; - st_mysql_plugin::version is a good candidate for clean-up.
[9 Jul 2013 15:23]
Hartmut Holzgraefe
See also earlier request http://bugs.mysql.com/bug.php?id=27835