Исходное сообщение
"Рассматривается переход СУБД PostgreSQL на новую нумерацию в..." Отправлено _hide_, 20-Май-16 10:14
Зачем? Major1 - ломаем совместимость с SQL-ом прошлой версии (ну или наполняем новыми конструкциями, которые в старом работать ну никак не будут). Major2 - серьезные фичи, рефакторинг, улучшение внутренних алгоритмов и т.п. Minor - мелкие фичи, баг фиксы и прочие исправления Или не получается делать изменений на Major2, а хотят всем показать, какие они молодцы? Или просто не могут объяснить инвесторам, что самым правильным подходом является: в отдельной ветке идет аккумулирование изменений и улучшений (develop version) и в основной мелкие улучшения параллельно с багфиксами (inc minor), которые потом торжественно сливаются и готовится новая версия (inc major2). В определенный момент (работы по 3 предыдущим моментам) становится понятно, что нужно что-то менять (к примеру новые возможности в develop version представляют из себя коллекцию костылей примотанных скотчем) и нужны глобальные изменения. В develop version начинают добавлять архитектурные изменения, а в основной идет только прием багфиксов. Релиз (inc major1). И дальше цикл с самого начала. А что хотят сделать? Просто все смешать в одно, люди, кони, архитектурные изменения, структура проекта все в перемешку и в продакшен. Да и Мы прекрасно знаем, к чему это приводит: 1. Гонка версий и изменений: независимые разработчики гнаться не смогут и будут делать форк 2. Архитектура костенеет, а поскольку в новом подходе возникнут серьезные проблемы при внесении изменений затрагивающие множество зависимостей (никто не может успеть везде, а этапа архитектурных изменений не предвидится) 3. В лучшем случае это приведет в уменьшению количества активных разработчиков и выкидыванию "старых фич". В худшем - к прекращению активной разработки и поддержке имеющего функционала и превращению СУБД в ещё один проект фонда апач.