На прошедшей встрече разработчиков PostgreSQL рассмотрен (http://www.databasesoup.com/2016/05/changing-postgresql-vers...) переход на новую нумерацию выпусков. В текущей трёхуровневневой нумерации (Major1.Major2.Minor) первое число потеряло свой смысл, но вводит некоторых пользователей в заблуждение, требуя пояснять, что второй номер также указывает на значительный релиз. Поэтому предлагается упростить нумерацию и перейти к более понятной схеме "Major.Minor", в которой "Major" указывает номер значительной ветки, а "Minor" - номер корректирующего обновления, не требующего перезаливки БД. Значительные релизы PostgreSQL выпускаются раз в год. Если новая схема будет утверждена, то следующий значительный выпуск получит номер 10.0 вместо 9.6.0.

URL: http://www.databasesoup.com/2016/05/changing-postgresql-vers...
Новость: http://www.opennet.me/opennews/art.shtml?num=44463

• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,A.Stahl, 22:15 , 19-Май-16
  • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Аноним, 02:27 , 20-Май-16
    • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,_hide_, 10:14 , 20-Май-16
      • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Stax, 13:52 , 20-Май-16
  • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,RaSla, 07:03 , 20-Май-16
    • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Andrey Mitrofanov, 11:09 , 20-Май-16
  • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,arikhin, 08:29 , 20-Май-16
• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Аноним, 22:29 , 19-Май-16
  • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Andrey Mitrofanov, 10:24 , 20-Май-16
• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,_, 22:48 , 19-Май-16
  • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,жабабыдлокодер, 23:13 , 19-Май-16
    • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,A.Stahl, 23:27 , 19-Май-16
• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Pilat, 02:44 , 20-Май-16
• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Вареник, 05:22 , 20-Май-16
  • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Аноним, 18:50 , 21-Май-16
• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,fvl, 08:54 , 20-Май-16
• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Аноним, 11:57 , 20-Май-16
• Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Kodir, 22:46 , 20-Май-16
  • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Led, 23:24 , 20-Май-16
    • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Kodir, 12:47 , 21-Май-16
      • Рассматривается переход СУБД PostgreSQL на новую нумерацию в...,Led, 19:37 , 21-Май-16

И почему, спрашивается, изначально нельзя было использовать правильно трёхуровневый вариант? Ведь будет нехватка цифр. Точно ведь говорю. И полезут всякие 10.0a, 10.1bis, 10.1 RC3...

Для совсем-уж-маленьких фиксов смогут сделать третью циферку, но по дефолту её не будет. Почему бы не так?

Зачем?
Major1 - ломаем совместимость с SQL-ом прошлой версии (ну или наполняем новыми конструкциями, которые в старом работать ну никак не будут).
Major2 - серьезные фичи, рефакторинг, улучшение внутренних алгоритмов и т.п.
Minor - мелкие фичи, баг фиксы и прочие исправления

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

Такая схема не будет работать. Каждый не-багфикс релиз постгреса (как минимум в рамках последних 8 и всех 9-ок - более ранние не видел) всегда был major1 по такой терминологии. Более того, не только постоянно дополняют новыми конструкциями / типами / фичами, которые в старом работать не будут, они меняют формат внутренних таблиц, а иногда и бинарных данных. И переходить с версии на версию можно только через dump/restore.

По факту сейчас есть два типа релизов постгреса
1) секьюрити фиксы и багфиксы (накручивается последняя цифра), переходить обычно можно просто обновлением - но иногда после перехода-таки нужно что-то сделать, чтобы багфикс активировался, напр. пересоздать индексы, поэтому обновляться - кроме как совсем требовательного продакшена - обычно можно, но релизноты прочесть стоит.
2) добавляют новые несовместимые фичи, иногда даже ломают обратную совместимость (чаще в расширениях, но бывает и в основном коде), меняют формат, автоматический переход невозможен - читаем релизноты и организуем вручную, обычно с приличным даунтаймом. Накручивается средняя цифра. Репозитории устроены так, что автоматическое обновление на такую версию никогда не произойдет.

Иногда, когда средняя цифра слишком большая, а фич накрутили уж совсем много, накручивают первую. Принципиально ничем не отличается от накрутки средней.

Сейчас они просто отказываются от последнего правила, которое слишком нестрого. И убирают бывшую старшую версию. Ну а чтобы версионность не сломалась (и версия была больше, чем 9.5), начинают с 10. Новая вторая цифра - бывшая третья, все просто.

Какие еще гонки, люди, кони?... В процессе разработки вообще ничего не меняется, просто выкидывается старшая цифра, т.к. она ничего не значит уже много лет, все определяется (бывшей) средней, которая теперь становится первой, как по сути оно и есть.

Возможно, потому что теперь переходят на "Семантическое Версионирование"
http://semver.org/lang/ru/

> Возможно, потому что теперь переходят на "Семантическое Версионирование"
> http://semver.org/lang/ru/

Я считаю, Debian —̶в̶с̶ё— версии сделал правильно!

Version: 3.16.7-ckt20-1+deb8u3~bpo70+1

-- sed -r 's/./\xcc\xb6&/g;s/^|$/\xe2\x80\x94/g' <<<'всё' >~/pub_html/file.txt

> И почему, спрашивается, изначально нельзя было использовать правильно трёхуровневый вариант?
> Ведь будет нехватка цифр. Точно ведь говорю. И полезут всякие 10.0a,
> 10.1bis, 10.1 RC3...

числа используй 10.154864

точно, прейти следующим шагом на 960 вместо 9.6.0! инвесторы деньгами истекут сразу