Oracle fails the context by make incompatible ABI changes which are *expected* by raise the minor release number but claim they are compatible until it is clear that random things are broken and the soname needs to be changed what leaves the question: was the QA at holiday due the whole development cycle?
* MySQL 5.5.8 was the GA release * MySQL 5.5.10 changed the soname * *wow* the same happens now again with 5.6? * this leaded in mass-rebuilds for linux-distributions after GA * maybe one of the reasons why Oracle MySQL get dropped everywhere and replaced by MariaDB and instead to accept the fact as example in Fedora Oracle stepped in and make things more complicated by try to figure out how both forks can be in the distribution instead doing a clean cut everybody but Oracle knows when you need to raise the so-number to make sure any package-managment prevents the enduser to end in incompatible linked applications, if the so-number would be raised RPM would *not allow* to install the new client library until all depending packages are rebuilt and if something like the 5.5.10 breakage happens more than once i claim someone to be learning resistent > Changes in MySQL 5.5.10 (2011-03-15) > > Incompatible Change: The shared library version of the client library was > increased to 18 to reflect ABI changes, and avoid compatibility problems > with the client library in MySQL 5.1. Note that this is an incompatible > change between 5.5.10 and earlier 5.5 versions, so client programs that > use the 5.5 client library should be recompiled against the 5.5.10 client > library. (Bug #60061, Bug #11827366) Am 17.05.2013 11:10, schrieb Sebastien FLAESCH: > Could someone from the libmysqlclient contributors comment on this, and > could someone complete the documentation regarding client compatiblity? > > On 02/20/2013 09:31 AM, Sebastien FLAESCH wrote: >> Hello, >> >> FYI, I found this statement in the doc, at the end of the C API main page: >> >> http://dev.mysql.com/doc/refman/5.6/en/c.html >> >> If, after an upgrade, you experience problems with compiled client >> programs, such as Commands out of sync or unexpected core dumps, you >> probably have used old header or library files when compiling your >> programs. In this case, check the date for your mysql.h file and >> libmysqlclient.a library to verify that they are from the new MySQL >> distribution. If not, recompile your programs with the new headers and >> libraries. Recompilation might also be necessary for programs compiled >> against the shared client library if the library major version number >> has changed (for example from libmysqlclient.so.15 to libmysqlclient.so.16. >> >> ... >> >> This sounds like guessing/hoping that the a client program compiled/linked >> with older headers/libmysqlclient can eventually work with a more recent >> client lib. >> >> There should be a clear rule for that. >> >> A simple rule could be that it's mandatory to recompile when upgrading to >> a new production release (5.5 to 5.6), even if the client libs are still >> compatible. >> >> Further, I would expect to see such note in "Building Client Programs": >> >> http://dev.mysql.com/doc/refman/5.6/en/building-clients.html >> >> Seb > > -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
signature.asc
Description: OpenPGP digital signature
