| 1.1, A.Stahl (ok), 22:15, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
 И почему, спрашивается, изначально нельзя было использовать правильно трёхуровневый вариант? Ведь будет нехватка цифр. Точно ведь говорю. И полезут всякие 10.0a, 10.1bis, 10.1 RC3...
| | |
| |
| 2.6, Аноним (-), 02:27, 20/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Для совсем-уж-маленьких фиксов смогут сделать третью циферку, но по дефолту её не будет. Почему бы не так?
| | |
| |
| 3.12, _hide_ (ok), 10:14, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Зачем?
Major1 - ломаем совместимость с SQL-ом прошлой версии (ну или наполняем новыми конструкциями, которые в старом работать ну никак не будут).
Major2 - серьезные фичи, рефакторинг, улучшение внутренних алгоритмов и т.п.
Minor - мелкие фичи, баг фиксы и прочие исправления
Или не получается делать изменений на Major2, а хотят всем показать, какие они молодцы? Или просто не могут объяснить инвесторам, что самым правильным подходом является: в отдельной ветке идет аккумулирование изменений и улучшений (develop version) и в основной мелкие улучшения параллельно с багфиксами (inc minor), которые потом торжественно сливаются и готовится новая версия (inc major2). В определенный момент (работы по 3 предыдущим моментам) становится понятно, что нужно что-то менять (к примеру новые возможности в develop version представляют из себя коллекцию костылей примотанных скотчем) и нужны глобальные изменения. В develop version начинают добавлять архитектурные изменения, а в основной идет только прием багфиксов. Релиз (inc major1). И дальше цикл с самого начала.
А что хотят сделать? Просто все смешать в одно, люди, кони, архитектурные изменения, структура проекта все в перемешку и в продакшен.
Да и Мы прекрасно знаем, к чему это приводит:
1. Гонка версий и изменений: независимые разработчики гнаться не смогут и будут делать форк
2. Архитектура костенеет, а поскольку в новом подходе возникнут серьезные проблемы при внесении изменений затрагивающие множество зависимостей (никто не может успеть везде, а этапа архитектурных изменений не предвидится)
3. В лучшем случае это приведет в уменьшению количества активных разработчиков и выкидыванию "старых фич". В худшем - к прекращению активной разработки и поддержке имеющего функционала и превращению СУБД в ещё один проект фонда апач.
| | |
| |
| 4.16, Stax (ok), 13:52, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Такая схема не будет работать. Каждый не-багфикс релиз постгреса (как минимум в рамках последних 8 и всех 9-ок - более ранние не видел) всегда был major1 по такой терминологии. Более того, не только постоянно дополняют новыми конструкциями / типами / фичами, которые в старом работать не будут, они меняют формат внутренних таблиц, а иногда и бинарных данных. И переходить с версии на версию можно только через dump/restore.
По факту сейчас есть два типа релизов постгреса
1) секьюрити фиксы и багфиксы (накручивается последняя цифра), переходить обычно можно просто обновлением - но иногда после перехода-таки нужно что-то сделать, чтобы багфикс активировался, напр. пересоздать индексы, поэтому обновляться - кроме как совсем требовательного продакшена - обычно можно, но релизноты прочесть стоит.
2) добавляют новые несовместимые фичи, иногда даже ломают обратную совместимость (чаще в расширениях, но бывает и в основном коде), меняют формат, автоматический переход невозможен - читаем релизноты и организуем вручную, обычно с приличным даунтаймом. Накручивается средняя цифра. Репозитории устроены так, что автоматическое обновление на такую версию никогда не произойдет.
Иногда, когда средняя цифра слишком большая, а фич накрутили уж совсем много, накручивают первую. Принципиально ничем не отличается от накрутки средней.
Сейчас они просто отказываются от последнего правила, которое слишком нестрого. И убирают бывшую старшую версию. Ну а чтобы версионность не сломалась (и версия была больше, чем 9.5), начинают с 10. Новая вторая цифра - бывшая третья, все просто.
Какие еще гонки, люди, кони?... В процессе разработки вообще ничего не меняется, просто выкидывается старшая цифра, т.к. она ничего не значит уже много лет, все определяется (бывшей) средней, которая теперь становится первой, как по сути оно и есть.
| | |
|
|
| |
| 3.14, Andrey Mitrofanov (?), 11:09, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Возможно, потому что теперь переходят на "Семантическое Версионирование"
> http://semver.org/lang/ru/
Я считаю, Debian —̶в̶с̶ё— версии сделал правильно![CODE]Version: 3.16.7-ckt20-1+deb8u3~bpo70+1[/CODE]
-- sed -r 's/./\xcc\xb6&/g;s/^|$/\xe2\x80\x94/g' <<<'всё' >~/pub_html/file.txt
| | |
|
| 2.10, arikhin (ok), 08:29, 20/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > И почему, спрашивается, изначально нельзя было использовать правильно трёхуровневый вариант?
> Ведь будет нехватка цифр. Точно ведь говорю. И полезут всякие 10.0a,
> 10.1bis, 10.1 RC3...
числа используй 10.154864
| | |
|
| 1.2, Аноним (-), 22:29, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
точно, прейти следующим шагом на 960 вместо 9.6.0! инвесторы деньгами истекут сразу
| | |
| |
| 2.13, Andrey Mitrofanov (?), 10:24, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> точно, прейти следующим шагом на 960 вместо 9.6.0! инвесторы деньгами истекут сразу
Рано! Смотри:[CODE[8.1.1
9.6.0
10.0
199[/CODE]
А после 999 настанет ОН. //Да, старпёры и ретрограды ещё при переходе с 99.9 на "100" при _ликвидации_ минорных релизов и фиксов, будут гундеть, что "все пропало".
A99 ,, AFF , B00 .. B99 ... BFG ... BFF, C00 ... FFF ...
...
...
ZZZ... Хрррр...
| | |
|
| 1.7, Pilat (ok), 02:44, 20/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Для специалистов по PostgreSQL система нумерации большого значения не имеет, так что если изменение системы поможет в его продвижении - прекрасно, пусть меняют. Только не стоит это обосновывать какими-то потерянными смыслами.
| | |
| 1.8, Вареник (?), 05:22, 20/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Последнее что повлияет на выбор в какой-нибудь назревшей миграции с Оракла на Постгрес - это скорость увеличения цифр в версии одного или другого.
| | |
| |
| 2.20, Аноним (-), 18:50, 21/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Последнее что повлияет на выбор в какой-нибудь назревшей миграции с Оракла на
> Постгрес - это скорость увеличения цифр в версии одного или другого.
Влажные мечты, ха. Ну, пойди, заставь какой-нибудь банчок мигрировать в таком направлении. Расскажешь, куда послали, угумс?
| | |
|
| 1.17, Kodir (ok), 22:46, 20/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Первая цифра из триады действительно как-то бестолково упоминается - когда её увеличивать? Когда сломали нафик всю совместимость? Тогда накой нужна такая либа, где нужно смотреть ещё и на первый номер? Проще создать либу с новым именем.
| | |
| |
| 2.18, Led (ok), 23:24, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > Тогда накой нужна такая либа, где
> нужно смотреть ещё и на первый номер? Проще создать либу с
> новым именем.
"Имя с первым номером" - это не просто имя, а фамилия.
| | |
| |
| 3.19, Kodir (ok), 12:47, 21/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Наоборот: название либы - фамилия, а первый номер - постоянно плодящиеся дети :)
А форк - это вообще "от соседа"!
| | |
| |
| 4.21, Led (ok), 19:37, 21/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Наоборот: название либы - фамилия, а первый номер - постоянно плодящиеся дети
Да, ламерок, намёк на soname ты не понял...
| | |
|
|
|
|
