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:
None 
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
Description:
Which plugin am I using?

I built 5.1.38 with the included Innodb 1.0.4 plugin. But the plugins table only displays the first 2 digits for versions (1.0). I request that this be changed to display 1.0.4 or 1.04 or something that specifies the real version.

This tells me:
mysql> show variables like "innodb_version"\G
*************************** 1. row ***************************
Variable_name: innodb_version
        Value: 1.0.4

This does not
mysql> select * from plugins where PLUGIN_NAME="InnoDB"\G
*************************** 1. row ***************************
           PLUGIN_NAME: InnoDB
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: STORAGE ENGINE
   PLUGIN_TYPE_VERSION: 50138.0
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Innobase Oy
    PLUGIN_DESCRIPTION: Supports transactions, row-level locking, and foreign keys
        PLUGIN_LICENSE: GPL

How to repeat:
Use 5.1.38 with the innodb plugin and run the SQL listed above

Suggested fix:
Display the result as 1.04
[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