Pull to refresh

Comments 21

Просто офигенная причина для поднятия мажорной версии: «беспокоиться из-за больших чисел выпусков в ветке 5.хх»!!! А давайте тогда сразу версию 10 сделаем — а что, красиво! Я в этой жизни явно что-то не понимаю…
Написано, кажется, вполне однозначно.

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

Гораздо хуже обратная ситуация: поменялась minor версия, но изменения ломают обратную совместимость 🤦🏻‍♂️

Так то да, но я не вижу её нарушения в данном случае; Линус согласно трактовке SemVer имеет полное право назвать следующий релиз 6.0.0 если считает, что добавление нового языка в ядро это оправдывает и что номера становятся слишком большими

Я языком — согласен. А вот «и что номера становятся слишком большими» — такие причины как-то настораживают)

Конкретно в случае с линуксом это будет сложно. Обратную совместимость для юзерспейса сохраняют очень жёстко и там мажорная будет всегда 1 покуда Линус жив. Внутреннее же апи так или иначе ломается постоянно и если из-за него инкрементить мажорную, то она быстро потеряет свой смысл. Так или иначе, получаются какие-то большие нечего не значащие числа. Ну, версия патча из семвера остаётся, но она и так вроде есть.

Номера версий линукса мало что значат, да и мажорный номер уже не первый раз увеличивается потому что минорный стал слишком большим числом. Наверное, можно было бы нумеровать как браузеры где уже далеко за 100+, но и текущий вариант не хуже.

Точно, не Chrome. Firefox поддерживал такое поведение, но тоже начал менять версию как Chrome. Хотя, кто знает, может они с каждым релизом добавляют какие-то обратно несовместимые возможности.

Проблема не в том, «какая мне разница», а в том, что от разработчиков ожидается какая-то логичность, которая ввиду проффдеформации подсознательно распространяется на всё. Для упрощения разработки принято придерживаться некоторых правил — выше уже упомянули SemVer. Вы вообще себе представляете объём корректировок, если каждый разработчик будет версии давать в зависимости от того с какой ноги утром встанет?

Зачем вы распространяете конкретный случай на всех разработчиков?


Речь идёт о конкретном проекте, у которого есть свой порядок выпуска и свой подход к работе с кодом. Исторически ядро предусматривает такой принцип, что обновления не должны ломать юзерспейс. Если про это не забывать, то в целом нет никакого значения, какая там версия — 5.20, 6.0 или 12345, если она монотонно увеличивается каждые несколько месяцев.


В таком контексте деление на мажорные и минорные версии имеет чисто номинальный характер и не отражает абсолютно ничего. Что, собственно, Линус говорил уже не один раз.

ну так-то да, но тогда нумерация в духе убунты более уместна, не находите?

Не нахожу. Мне просто без разницы, какой там номер версии и как он формируется, пока можно сказать что версия Y вышла после версии X.
Так сложилось, что они нумеруются как сейчас, ну и ладно. Вместо того чтобы стулья переставлять, пускай люди работу работают. В сущности не изменится абсолютно ничего, если поменять схему версионирования.

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

У «нумерации в духе убунты» есть ещё один минус — создаётся путаница, если релиз по каким-то причинам сдвинется. Особенно этим страдают разработчики OpenWrt, у которых версия 19.07 вышла в начале 2020 года, а версия 21.02 — в сентябре 2021.
Линус прямо указал, что большие числа его беспокоят, а вы предлагаете добавить беспокойства.

ok, принято )


У «нумерации в духе убунты» есть ещё один минус — создаётся путаница, если релиз по каким-то причинам сдвинется. Особенно этим страдают разработчики OpenWrt, у которых версия 19.07 вышла в начале 2020 года, а версия 21.02 — в сентябре 2021

пока не выходит 21.08, которая по факту младше 21.02, это не проблема.
не вижу ничего плохого, если для номера релиза используется не дата выхода релиза, а дата feature freeze

Ядро, наверное, постарее будет, чем концепция SemVer, поэтому не стоит делать из семантического версионирования культ.

Вообще, Линус давно уже мог бы вообще отказаться от первого или второго числа в номере версии. Ядро релизится точно так же, как и современные браузеры — вне зависимости от того, сколько коммитов поступило (и насколько они были революционны), строго по графику. Поэтому можно было бы просто увеличивать первое число на единицу в каждом релизе. Сейчас увеличивается второе число, а когда Линусу становится некомфортно, оно сбрасывается в ноль и увеличивается первое.

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

Слышал байку, что Линус минорные версии по пальцам считает, когда пальцы заканчиваются, происходит переход на следующую мажорную версию.

Так не байка же, вроде. Он это как-то в интервью сказал, когда в прошлый раз решил перейти с 4.x версии на 5.0

Вот это вот… это всё объясняет. И логика, главное, есть!)
Переход 2.6.40 -> 3.0 — сколько пальцев задействовано?
Sign up to leave a comment.

Other news