Комментарии 17
А для чего он ещё есть? Уже устарел давно
И это всё? В сравнении даже с одним commitfest PostgreSQL - это очень и очень мало. Oracle что-ли убивает MySQL, практически остановив его развитие?
Это Innovation ветка, там новые фичи и новый релиз выходит каждые 3 мес. Поэтому 3-4 фичи за 3 месяца кажутся вполне нормальным явлением. Зато не нужно ждать 1 год манны небесной как в случае с PostgreSQL, а в итоге не получить того что ждеш целый год.
Не понял о чем Вы. Периодичность commitfest PostgreSQL - 2-3 месяца. И в каждом видим порядка сотни коммитов. Ну пусть даже треть - багфиксы. Все равно получается свыше полусотни фич каждые 2-3 месяца.
В минорных версиях пг нет нового функционала, просто откройте релиз нотес
https://www.postgresql.org/docs/release/16.1/
https://www.postgresql.org/docs/release/16.2/
И другие и увидите там сплошные фиксы
Их много, но о чем это говорит? О наличии горы багов, которые исправляют.
Я не спорю что пг развивается более динамично чем мускуль, но и в пг хватает странностей.
Вот например в 17 версию не дотащили поддержку uuid v7, ну смешно же, патч то простой, но нет. Когда дотащу какой-нибудь 64 битный счетчик транзакций - ну дай бо к 22 версии может быть.
Почему Вы упорно занимаетесь демагогией, подменяя тему?
Я что писал?
В сравнении даже с одним commitfest PostgreSQL
При чем тут вообще релизы?
Их много, но о чем это говорит? О наличии горы багов, которые исправляют.
В первую очередь, это говорит о том, количество багов, которые неизбежны в любом программном продукте, активно уменьшается. И чем больше я вижу коммитов с исправление багов в проекте, тем значит меньше он их содержит. И наоборот, если в проекте баги исправляются редко, то значит их там действительно горы.
Вот например в 17 версию не дотащили поддержку uuid v7
Все претензии к Бордину, который выдал последний патч только вчера
Одно дело, впихнуть UUIDv7 где-то сбоку. Сбоку он и так есть. А совсем другое дело - в ядро. Там целая Санта-Барбара получилась.
Статья про релиз mysql, причем тут комитфесты пг вообще непонятно. Давайте еще кол. комитов посчитаем?
У mysql и pg разные циклы выпуска релизов, дак какой смысл что-то сравнивать?
>И наоборот, если в проекте баги исправляются редко, то значит их там действительно горы.
Да с чего вы взяли если исправлений мало значит багов много? Вы анализировали багтрекер mysql? Можете поделиться статистикой сколько подтвержденных багов не закрыто?
Не думаете, что если мало исправлений, то это значит что мало багов? Или это невозможно в Вашей парадигме мира мускуля?
Вы анализировали багтрекер mysql? Можете поделиться статистикой сколько подтвержденных багов не закрыто?
Самому что-ли влом посмотреть? Сейчас активных (Open+Verified) 11374. Закрыто в 9.1 - чуть больше сотни. Но к чему это?
Не думаете, что если мало исправлений, то это значит что мало багов?
Как разработчик с тридцатилетним стажем, занимавшийся разработкой весьма крупных и разных проектов, я в это не поверю. Мало багов может быть только в проекте, который вообще не развивается, но хорошо поддерживается.
>Самому что-ли влом посмотреть? Сейчас активных (Open+Verified) 11374. Закрыто в 9.1 - чуть больше сотни. Но к чему это?
К тому, что у MySQL (текущей LTS версии - 8.4) всего 0 подтвержденных багов. Просто задайте правильный фильтр.
Я не утверждаю что MySQL супер-качественный продукт, просто это ответ на Ваш вопрос почему так мало исправлений. Ну если нет баго - что исправлять?
Про появление новых фичей я уже писал, что 3-4 новые фичи в пределах 3 месяцев разработки ИМХО вполне адекватная цифра. Я допускаю, что для Вас это мало - ну извините, наверно стабильность продукта для Oracle важнее пиления новых фичей.
К тому, что у MySQL (текущей LTS версии - 8.4) всего 0 подтвержденных багов. Просто задайте правильный фильтр.
Ну если по-вашему правильный фильтр - это исключить тысячи до сих пор неисправленных багов в предыдущих версиях, то я не понимаю, о чем можно дальше дискутировать.
Хотя даже тут солгали
Почему должны исправляться баги к версиям которые уже не поддерживаются?
Скрин вашего фильтра пожалуйста приложите прежде чем говорить что я солгал. Я привел Вам свой скрин фильтра и он относится к ветке 8.4 LTS и только к MySQL Server, всякие Connector и прочие подсистемы не относящиеся к ядру БД мы исключаем.
А перейти по ссылке, увидеть все значения фильтра в URL и убедиться, что в том числе и строк с "MySQL Server: *" там полно гордость не позволяет?
Я просто не стал фильтровать по категории, вполне обосновано полагая, что фильтр будет по тупому совпадению, а не по префиксу. И оказался прав.
Почему должны исправляться баги к версиям которые уже не поддерживаются?
Потому что они должны быть либо закрыты, если исправлены в следующих версиях, либо остаются в них.
Ваш фильтр оказался полной фигней, тк включает баги в компонентах не относящихся к серверу и даже к версии 8.4
Хотя и мой тоже странный, на лицо кривость багтрекера.
Соглашусь что какая то порция багов в 8.4 есть, но они довольно странные и скорее всего не будут закрыты.
И да, это странно что неподтвержденные баги не закрывают и они висят.
Ну если для Вас переименование столбцов в pg_stat_statements (я про 17 версию) является фичей, ну ОК. Тогда да, в PG будут сотни таких "фич"
Я тоже практически всю жизнь скептически смотрел на mysql.
Пока в силу обстоятельстве в одном HL, HA проекте не был использован Oracle MySql 8
С тех пор кардинально изменил мнение об mysql в частности. И какой либо технологии в общем.
зы
у mysql - вагон форков, возможно далеко не все форки хороши. моя оценка про оракловый mysql
Вышла СУБД MySQL 9.0.0