maria-discuss team mailing list archive
Mailing list archive
Re: MariaDB 5.5.34 now available
Mailing-List mariadb <"maria-discuss"@lists.launchpad.net>
Reindl Harald <h.reindl@xxxxxxxxxxxxx>
Thu, 21 Nov 2013 20:05:49 +0100
the lounge interactive design
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
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?
>> 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"....
Description: OpenPGP digital signature