We hand over positions?

In the last half of the year, I have a dual impression of using MySQL. I do not want to evaluate the work done by Oracle, as a management company, but I really want to comment on the fact that already 5 releases cannot wait for a stable version of MySQL, which will allow to work normally.

5.5.19
The long-awaited release came out in which they fixed the bug bugs.mysql.com/bug.php?id=56299 , thanks to which every switch of logs on our database had to be monitored, in view of a possible freeze of a sale due to replication bugs.mysql.com/bug.php ? id = 61186 .
While we were testing the release, we realized that when using MySQL partitions it shamelessly flows. The developers claim that it is not it flowing, but the memory is fragmented blogs.innodb.com/wp/2011/12/improving-innodb-memory-usage-continued

BUT! those. if my OS cannot use the memory that MySQL used, it certainly doesn’t have to be blamed on the OS.
5.5.21
I waited for the bug fix bugs.mysql.com/bug.php?id=57480 . Backport from 5.6.5 came fixed, thanks to which MySQL does not need to be reloaded every month, due to the swap filling. But then a new surprise arose! Which of course is old, but for PCI DSS assessors is a red rag, because you can get into the database without a password: seclists.org/oss-sec/2012/q2/493 . The problem was well lit on habrahabr.ru/post/145641 . All versions prior to 5.5.22 are vulnerable. We ourselves are not fast, we test, download the source code patch.
5.5.25
While patch and test out 5.5.25. Well, like there are a lot of fixes, we decided to put it. A month ago, we started the process of testing this version. I am writing a ticket, here bang surprise! Sources of this version are missing from the site. There is a patch, we can not collect it, because there is no source to download the source code. The reason is trivial bugs.mysql.com/bug.php?id=65745 . Update the primary key (I do not know who came up with the update primary key) causes a recursive change of data, which leads to filling the entire place on the HDD.
5.5.25a
Hooray released a new version. So there everything should work. We check the work: suddenly one of the developers says that he has MySQL falling on any request. We are checking. And the truth is, if you request data from a partitioned table for a non-existent period, MySQL crashes

12:06:58 UTC - mysqld got signal 8 ; This could be because you hit a bug. ... Thread pointer: 0x4169f30 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7ff9fa384e58 thread_stack 0x30000 /opt/mysql-5.5.25a/bin/mysqld(my_print_stacktrace+0x29)[0x75feb9] ... /opt/mysql-5.5.25a/bin/mysqld(pfs_spawn_thread+0x54)[0x879cf4] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7efc)[0x7ffa669e8efc] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ffa65d5b59d] 

Checking - all versions up to 5.5.22 are vulnerable, but you can enter 5.5.22 without a password. I do not know what to do. We're sitting scratching turnips. I, for example, after running this script (which we wrote all day), overload Ubuntu.

 use test_mysql_crash; drop table if exists test_table; create table test_table ( agad_id int(10) unsigned not null auto_increment, partition_key int(8) not null default '0', caaf_caaf_id int(10) unsigned default null, primary key (agad_id,partition_key), key idx_1 (partition_key), key idx_2 (caaf_caaf_id) ) engine=innodb partition by range (partition_key) (partition test_table_20120717 values less than (20120718) engine = innodb, partition test_table_20120718 values less than (20120719) engine = innodb, partition test_table_20120719 values less than (20120720) engine = innodb, partition test_table_20120720 values less than (20120721) engine = innodb, partition test_table_20120721 values less than (20120722) engine = innodb); drop procedure if exists ui_test_mysql_crash; delimiter $$ create procedure ui_test_mysql_crash() main_sql: begin declare v_sql_core text; set v_sql_core = concat( ' explain select caaf_caaf_id, ', ' partition_key ', ' from test_table ', ' where partition_key between ? and ? ', ' group by caaf_caaf_id, partition_key' ); set @sv_ddl_statement = v_sql_core; set @sv_partition_key_from = 20120801; set @sv_partition_key_to = 20120831; prepare v_stmt from @sv_ddl_statement; execute v_stmt using @sv_partition_key_from, @sv_partition_key_to; deallocate prepare v_stmt; end $$ delimiter ; call ui_test_mysql_crash; 

Well, comment on the bug bugs.mysql.com/bug.php?id=65587 and wait ...

PS Of course, all events are not chronological, I just wanted to describe that in all the latest versions something is wrong ...

Update: shagguboy correctly noted - in one bug it is written that in 5.5.26 the last bug is already fixed, for which he thanks, and yes I am waiting for the next version again (IMHO is extremely symbolic)