MySQL Bugs: #47420: information_schema.plugins.PLUGIN_VERSION doesn't specify the full version

Bug #47420	information_schema.plugins.PLUGIN_VERSION doesn't specify the full version
Submitted:	17 Sep 20:34	Modified:	17 Nov 4:41
Reporter:	Mark Callaghan
Status:	Verified
Category:	Server: I_S	Severity:	S3 (Non-critical)
Version:	5.1.38	OS:	Any
Assigned to:		Target Version:	5.4+
Tags:	innodb, plugin, information, schema
Triage:	Triaged: D3 (Medium)

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

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.

P.S. now I realize 1.04 is not possible, see the comment from univ.i

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.

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?

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

5. 104.0 (as PLUGIN_TYPE_VERSION)

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

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.