Make XtraDB honor version information from the VERSION file

[Alexey Kopytov]

This is what I see in 5.5:

VERSION contains:

MYSQL_VERSION_MAJOR=5
MYSQL_VERSION_MINOR=5
MYSQL_VERSION_PATCH=37
MYSQL_VERSION_EXTRA=-35.0

but in univ.i:

#ifndef PERCONA_INNODB_VERSION
#define PERCONA_INNODB_VERSION 34.2
#endif

Likewise in 5.6, VERSION:

MYSQL_VERSION_MAJOR=5
MYSQL_VERSION_MINOR=6
MYSQL_VERSION_PATCH=19
MYSQL_VERSION_EXTRA=-66.1

but in univ.i:

 #ifndef PERCONA_INNODB_VERSION
#define PERCONA_INNODB_VERSION 65.0
 #endif

[Tomislav Plavcic (tplavcic)]

Hi Alexey,
we are updating version in univ.i and also checking version in VERSION file on the release branch for every release.
for 5.5 in the trunk (file univ.i) I see:
#define PERCONA_INNODB_VERSION 35.1
which seems fine

and for 5.6 I see in the trunk in univ.i file>
#define PERCONA_INNODB_VERSION 66.0
which was ok for the last release.
There can be bigger version in VERSION file but that's because Laurynas merged upstream and bumped the version - we will change in the univ.i file also on the release branch for the next release.

Is that ok?

[Alexey Kopytov (akopytov)]

A better way would be to get rid of PERCONA_INNODB_VERSION altogether. It's never a good idea to maintain the same information in multiple places. There's nothing outstanding in making XtraDB honor the version defined in the VERSION file. Let's keep this as a request to implement that.

[Laurynas Biveinis (laurynas-biveinis)]

Version string local to storage/innobase is used by MariaDB XtraDB I guess. Removing it might inconvenience them a bit, but I agree that we shouldn't be maintaining it in two locations.

[Alexey Kopytov (akopytov)]

It doesn't necessarily have to be literally removed, but rather made dependent on information from the VERSION file instead of a hard-coded value.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1513