форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Рассматривается переход СУБД 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... Новость: http://www.opennet.me/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 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 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 | Индекс форумов | Темы | Пред. тема | След. тема