[NIXP] Линус Торвальдс устроил голосование за номер для следующего релиза ядра Linux: 3.20 или 4.0

[Vascom]

Ну прямо так и сказать, что в версии 19 сильные изменения. Чего бояться-то?

[MrClon]

19 или 18? А Может 20? Не помню, Надо погуглить. А так 4.0 после 3.1415 и всем и без слов понятно что будет интересно. Ну и так можно параллельно тянуть две ветки, экспериментальную, с осциллографами и лаборантками, и стабильную, с ынырпрайзом и библиотекаршами.

[Hephaestus]

http://semver.org/

Мажорная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения. Она МОЖЕТ включать в себя изменения, характерные для уровня минорных версий и патчей. Когда увеличивается мажорная версия, минорная и патч-версия ДОЛЖНЫ быть обнулены.

Из этого следует, что у Линуса сейчас нет никаких оснований для изменения номера версии. Если, конечно, он придерживается этой системы.

Кстати, там ведь не только про номера версий, но и про API.
Думаю, это полезно бы почитать Леннарту. У меня почему-то впечатление, что он это не читал.
Со стороны их процесс разработки выглядит так, будто они мечутся из угла в угол без какого-либо чёткого плана и, что самое печальное, неясна конечная цель (когда можно будет объявить, что продукт готов?). То есть, несмотря на непрекращающийся процесс разработки, получается такой продукт в состоянии вечной альфы.

[yoshakar]

Из этого следует

Вообще-то не следует: "если" - это не то же самое, что "если и только если".

[NickLion]

http://semver.org/

Мажорная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения. Она МОЖЕТ включать в себя изменения, характерные для уровня минорных версий и патчей. Когда увеличивается мажорная версия, минорная и патч-версия ДОЛЖНЫ быть обнулены.

Из этого следует, что у Линуса сейчас нет никаких оснований для изменения номера версии. Если, конечно, он придерживается этой системы.

Вообще-то в Linux то и дело появляются обратно несовместимые изменения. Например, в ядре 3.11 убрали num_physpages, который поломал сборку драйверов NVidia в своё время.

[drBatty]

Вообще-то в Linux то и дело появляются обратно несовместимые изменения. Например, в ядре 3.11 убрали num_physpages, который поломал сборку драйверов NVidia в своё время.

вообще-то это нормальное и предсказуемое явление.

[Hephaestus]

Вообще-то не следует: "если" - это не то же самое, что "если и только если".

Боюсь, что всё-таки следует.
В данном тексте не случайно разделены ДОЛЖЕН и МОЖЕТ.
Так вот, согласно обозначениям, принятым в данном тексте, указано, в каких случаях ДОЛЖНА меняться мажорная версия.
И это единственное указание на смену мажорной версии.
В каких случаях она МОЖЕТ меняться, кроме этого, отдельных указаний нет.
Таким образом, получается взаимно однозначное соответствие.
Во всяком случае, там нигде не сказано, что мажорная версия МОЖЕТ меняться в произвольный момент времени, по желанию разработчика, а Линус предлагает именно это. Впрочем, как я уже сказал, это всё справедливо, только если Линус придерживается данной схемы.

[drBatty]

2All
объясните пожалуйста, а какое это имеет значение? Я не троллю, я не понимаю.

[NickLion]

Вообще-то в Linux то и дело появляются обратно несовместимые изменения. Например, в ядре 3.11 убрали num_physpages, который поломал сборку драйверов NVidia в своё время.

вообще-то это нормальное и предсказуемое явление.

VBoxDrv тоже ломался, но не помню в какой версии. Практически все модули, которые не идут в поставке ядра и не следят за разработкой, иногда будут сталкиваються с проблемами. Потому что Linux не особо заботится об обратной совместимости. Это не плохо, это не хорошо, это просто надо учитывать. Поэтому приводить фактор, указанный ранее, для смены мажорной версии, то у Linux уже была мажорная версия порядка нескольких десятков

PS и да, имхо тоже, это не особо важно, лично я в той голосовалке проголосовал за 3.20, но не вижу ничего плохого и в 4.0.

[Bizdelnick]

Практически все модули, которые не идут в поставке ядра и не следят за разработкой, иногда будут сталкиваються с проблемами.

Это нормально. Проприерасты должны страдать.
Мажорная версия должна меняться при изменении внешнего, а не внутреннего API. Когда последний раз что-то ломали в системных вызовах?

[NickLion]

API взаимодействия с модулями также является публичным API.

[drBatty]

VBoxDrv тоже ломался, но не помню в какой версии.

в закрытой очевидно. Самого уже достало.

Потому что Linux не особо заботится об обратной совместимости.

Linux как раз заботится. Это вам к проприерастам ☺ которые кривые модули делают, и забывают их обновить.

Поэтому приводить фактор, указанный ранее, для смены мажорной версии, то у Linux уже была мажорная версия порядка нескольких десятков

что я пропустил? при чём тут версия?

ЗЫЖ простите за маленькие буквы, жру за клавой, шифты плохо давятся.

[NickLion]

Поэтому приводить фактор, указанный ранее, для смены мажорной версии, то у Linux уже была мажорная версия порядка нескольких десятков

что я пропустил? при чём тут версия?

Вот:

Мажорная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения.

[Hephaestus]

лично я в той голосовалке проголосовал за 3.20, но не вижу ничего плохого и в 4.0.

Я тоже сходил и проголосовал. Пришлось для этого нарисоваться в google+.
Я проголосовал за 3.20, но вижу, мнения в опросе хоть и разделились, всё же большая часть за 4.0.
Немного стало жаль, что плохо знаю буржуйский.
Гугель предложил сделать перевод страницы, уж не знаю насколько верно он это сделал, но я заметил, что аргументы некоторых сторонников 3.20 совпадают с моими.
То, что мы обсуждали выше по ссылке автор называет

system "Semantic Versioning."

то есть это система. А если эти правила нарушать в любой момент по своему желанию, то какая же это система? И главное, какой в ней тогда смысл?
Так что я всё-таки за систему. И за осмысленную нумерацию.

[Hephaestus]

Поэтому приводить фактор, указанный ранее, для смены мажорной версии, то у Linux уже была мажорная версия порядка нескольких десятков

Ну, что ж... Тоже верно. Однако, если уж придерживаться системы и отражать в нумерации важность изменений, то пусть было бы и несколько десятков, ничего страшного.
Добрались бы до 99, тогда и сбросили бы...
Опять же посмотрите на версии Volkov Commander - там другая крайность, но как иллюстрация сгодится.

[Bizdelnick]

Опять же посмотрите на версии Volkov Commander - там другая крайность, но как иллюстрация сгодится.

Последняя версия 4.05 (2001)

Где крайность?

[SLEDopit]

Опять же посмотрите на версии Volkov Commander - там другая крайность, но как иллюстрация сгодится.

Крайность? (:
Посмотрите на telnet. Aктуальная версия 0.17-36. Или ftp. Aктуальная версия 0.17-31.
Судя по changelog'y пилят как минимум с середины девяностых. А то и раньше.

Код: Выделить всё

 $ dpkg -l | grep -w "telnet\|ftp"
ii  ftp                                   0.17-31                           amd64        classical file transfer client
ii  telnet                                0.17-36                           amd64        The telnet client

[Hephaestus]

Где крайность?

Крайность? (:

Вы меня не поняли, почтенные сеньоры.
У VC были версии
4.00.036
4.00.037
4.00.038
4.00.039
4.00.040
то есть не менялась минорная версия, (а тем более мажорная), а менялся номер версии на уровне патча (в терминологии major.minor.patch). Хотя там были не только патчи, изменений, судя по описанию, хватило бы и на минорную версию.
Пруф
Вот такое использование нумерации мне представляется крайностью. То есть три числа - это хорошо, но злоупотреблять тоже не надо.

[Bizdelnick]

У VC были версии
4.00.036
4.00.037
4.00.038
4.00.039
4.00.040

Ну так по Вашей ссылке все эти версии помечены как beta. По сути они, выходит, были даже не beta, а скорее девелоперские. Для стабильных версий менялся минорный номер.
Нумерация нестабильных версий - это вообще отдельный вопрос...

[Hephaestus]

Ну так по Вашей ссылке все эти версии помечены как beta.

Да. Здесь, видимо, смысл номеров иной, чем мы обсуждаем.
Но лично я не вижу препятствий для изменения минорной версии даже у беты, если под этим подразумевается изменение функционала, а не просто патчи - баг-фиксы.
В конце концов, продукт может много месяцев пребывать в состоянии беты и при этом будет развиваться функционал. Тогда имеет смысл менять минорную версию. Не пихать же это всё в патчи, правда?
А вообще, грань между бетой и стабильным релизом всё же весьма зыбка, согласитесь.

[drBatty]

Мажорная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения.

это в помощь тем быдлокодерам, которые версию распарсить не могут?

Опять же посмотрите на версии Volkov Commander - там другая крайность, но как иллюстрация сгодится.

лучше на TeX посмотрите:

Последняя версия
3.14159265 (январь 2014)

Но лично я не вижу препятствий для изменения минорной версии даже у беты,

не, это уже бардак будет. Сложно поддерживать.

А вообще, грань между бетой и стабильным релизом всё же весьма зыбка, согласитесь.

вы не забывайте, сейчас все юзают DVCS, там куча веток в бете, а вот в релизе они стягиваются в одну(ну это в общих чертах конечно, на самом деле некоторые ветки переходят в следующий релиз минуя текущий).

Потому, если говорить об альфах и бетах, то по хорошему там номера вообще нет, и быть не может. Есть только идентификатор коммита.

[Vascom]

Вот и всё, вместо 3.20 будет 4.0 https://lkml.org/lkml/2015/2/22/203