maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Am 21.11.2013 20:01, schrieb Sergei Golubchik:
> On Nov 21, Reindl Harald wrote:
>> as far as i can say my private build for Fedora 19 x86_64 is fine
>> but Percona is greeting different as the changelog says
>>
>> how has "merge" to be recognized in this context?
>> include rel32 or merge cherry picking?
>>
>> https://mariadb.com/kb/en/mariadb-5534-changelog/
>> Percona-Server-5.5.34-rel32.0 merge
>>
>> Percona XtraDB (http://www.percona.com) 5.5.34-MariaDB-31.1 started; log sequence number 20195271610
> 
> Yes, sorry for this.
> 
> Percona is often forgetting to update the XtraDB version field.
> I've submitted bug reports about it, and, as far as I remember, they
> wanted to introduce some kind of a script of a trigger to make sure the
> version is always correct. But apparently they did not.
> 
> "Percona-Server-5.5.34-rel32.0 merge" means that I took XtraDB from
> Percona-Server-5.5.34-rel32.0.tar.gz source tarball.
> 
> But XtraDB version in that file (in storage/innobase/include/univ.i) is
> still 29.3. If you'd look in Percona Server, XtraDB would, most
> probably, announce itself as 5.5.34-29.3
> 
> In our sources it's 31.1 because, apparently, I've updated the version
> during the previous merge, but forgot to update now. I'm not much better
> than Percona when updating versions :(

no problem, versions are meaningless in doubt and the binary matters
better forget a version counter than slip a regression :-)

honestly in my own software i often do not care about raise the
version number over months because i am looking more at "well,
10% faster than before and no regressions"....

Attachment: signature.asc
Description: OpenPGP digital signature