The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от opennews (ok) on 19-Май-16, 22:15 
На прошедшей встрече разработчиков 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...
Новость: https://www.opennet.ru/opennews/art.shtml?num=44463

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +7 +/
Сообщение от A.Stahl (ok) on 19-Май-16, 22:15 
И почему, спрашивается, изначально нельзя было использовать правильно трёхуровневый вариант? Ведь будет нехватка цифр. Точно ведь говорю. И полезут всякие 10.0a, 10.1bis, 10.1 RC3...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  –1 +/
Сообщение от Аноним (??) on 20-Май-16, 02:27 
Для совсем-уж-маленьких фиксов смогут сделать третью циферку, но по дефолту её не будет. Почему бы не так?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

12. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от _hide_ (ok) on 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. В лучшем случае это приведет в уменьшению количества активных разработчиков и выкидыванию "старых фич". В худшем - к прекращению активной разработки и поддержке имеющего функционала и превращению СУБД в ещё один проект фонда апач.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

16. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Stax (ok) on 20-Май-16, 13:52 
Такая схема не будет работать. Каждый не-багфикс релиз постгреса (как минимум в рамках последних 8 и всех 9-ок - более ранние не видел) всегда был major1 по такой терминологии. Более того, не только постоянно дополняют новыми конструкциями / типами / фичами, которые в старом работать не будут, они меняют формат внутренних таблиц, а иногда и бинарных данных. И переходить с версии на версию можно только через dump/restore.

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

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

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

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

9. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  –3 +/
Сообщение от RaSla email on 20-Май-16, 07:03 
Возможно, потому что теперь переходят на "Семантическое Версионирование"
http://semver.org/lang/ru/
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

14. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Andrey Mitrofanov on 20-Май-16, 11:09 
> Возможно, потому что теперь переходят на "Семантическое Версионирование"
> 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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

10. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +1 +/
Сообщение от arikhin (ok) on 20-Май-16, 08:29 
> И почему, спрашивается, изначально нельзя было использовать правильно трёхуровневый вариант?
> Ведь будет нехватка цифр. Точно ведь говорю. И полезут всякие 10.0a,
> 10.1bis, 10.1 RC3...

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


Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +2 +/
Сообщение от Аноним (??) on 19-Май-16, 22:29 
точно, прейти следующим шагом на 960 вместо 9.6.0! инвесторы деньгами истекут сразу
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Andrey Mitrofanov on 20-Май-16, 10:24 
> точно, прейти следующим шагом на 960 вместо 9.6.0! инвесторы деньгами истекут сразу

Рано! Смотри:[CODE[8.1.1
9.6.0
10.0
199

А после 999 настанет ОН.  //Да, старпёры и ретрограды ещё при переходе с 99.9 на "100" при _ликвидации_ минорных релизов и фиксов, будут гундеть, что "все пропало".

A99 ,, AFF , B00 .. B99 ... BFG ... BFF, C00 ... FFF ...
...
...
ZZZ... Хрррр...

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  –1 +/
Сообщение от _ (??) on 19-Май-16, 22:48 
И ты Брутт ... :(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +2 +/
Сообщение от жабабыдлокодер (ok) on 19-Май-16, 23:13 
>Брутт

O tempora! O mores!

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +14 +/
Сообщение от A.Stahl (ok) on 19-Май-16, 23:27 
>Брутт

O massa! O netto!:)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Pilat (ok) on 20-Май-16, 02:44 
Для специалистов по PostgreSQL система нумерации большого значения не имеет, так что если изменение системы поможет в его продвижении - прекрасно, пусть меняют. Только не стоит это обосновывать какими-то потерянными смыслами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Вареник on 20-Май-16, 05:22 
Последнее что повлияет на выбор в какой-нибудь назревшей миграции с Оракла на Постгрес - это скорость увеличения цифр в версии одного или другого.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Аноним (??) on 21-Май-16, 18:50 
> Последнее что повлияет на выбор в какой-нибудь назревшей миграции с Оракла на
> Постгрес - это скорость увеличения цифр в версии одного или другого.

Влажные мечты, ха. Ну, пойди, заставь какой-нибудь банчок мигрировать в таком направлении. Расскажешь, куда послали, угумс?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от fvl email on 20-Май-16, 08:54 
вау, прям как мариадб.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Аноним (??) on 20-Май-16, 11:57 
фигня какая-то - должно быть три цифры
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  –1 +/
Сообщение от Kodir (ok) on 20-Май-16, 22:46 
Первая цифра из триады действительно как-то бестолково упоминается - когда её увеличивать? Когда сломали нафик всю совместимость? Тогда накой нужна такая либа, где нужно смотреть ещё и на первый номер? Проще создать либу с новым именем.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Led (ok) on 20-Май-16, 23:24 
> Тогда накой нужна такая либа, где
> нужно смотреть ещё и на первый номер? Проще создать либу с
> новым именем.

"Имя с первым номером" - это не просто имя, а фамилия.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Kodir (ok) on 21-Май-16, 12:47 
Наоборот: название либы - фамилия, а первый номер - постоянно плодящиеся дети :)
А форк - это вообще "от соседа"!
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "Рассматривается переход СУБД PostgreSQL на новую нумерацию в..."  +/
Сообщение от Led (ok) on 21-Май-16, 19:37 
> Наоборот: название либы - фамилия, а первый номер - постоянно плодящиеся дети

Да, ламерок, намёк на soname ты не понял...

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру