Почему я не поддерживаю семвер

А можно догонки перенести в конец видоса? Вроде заходишь тему послушать, а приходится левой инфы переждать. Если слушать не на ютубе, то проматать по таймкоду нельзя

Если пакет распространяется через npm/composer и он не использует semver, то это должно быть явно указано в документации. И при этом нельзя писать в документации инструкцию по установке так: npm install ilyabirman-likely —save, потому что по дефолту npm использует semver и пропишет в package.json например ^2.4.0. Если завтра вы дропните IE 10+ и сделаете релиз 2.4.1 или 2.5.0, а не 3.0.0, то все кто ставил ваш пакет при следующем автоапдейте дропнут IE и у себя. И не обязателен именно автоапдейт, просто сборка проекта со старым npm где нет package.lock.json тоже сломает его.

У меня недавно такое произошло с summernote, они решили что убирать совместимость с IE не стоит major версии и прописали это в третью цифру. Клиентский проект перестал собираться, я потратил 3 часа чтобы перелопатить все зависимости и найти что именно в этом пакете проблема и исправить. Неприятно.

5 лет назад про семвер хорошо написал Jeremy Ashkenas. Выдержка:

«If you pretend like SemVer is going to save you from ever having to deal with a breaking change — you’re going to be disappointed. It’s better to keep version numbers that reflect the real state and progress of a project, use descriptive changelogs to mark and annotate changes in behavior as they occur, avoid creating breaking changes in the first place whenever possible, and responsibly update your dependencies instead of blindly doing so.

Basically, Romantic Versioning, not Semantic Versioning.»

https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e

Понятный программистам пример — char (character). Тут тоже «к».

Денис Исайченко, то, что НПМ при установке зависимости добавляет к версии ^, подразумевая, что зависимость может быть автоматически обновлена до любой минорной версии выше — полный бред и факап. По умолчанию зависимость всегда должна ставиться жёстко той версии, которая устанавливается при подключении зависимости. Все обновления должны проходить ручной контроль разработчика/команды/тимлида. Апдейты не нужны, если только ты сам этого не попросил.

Евгений Лазарев, в новых версиях npm (5+) так и будет, т.к зависимость будет устанавливаться из lock файла. Правда в сети огромное число legacy проектов без lock файлов и отсутствие semver у зависимостей начинает стрелять.

Но я не согласен по поводу обновлений. Я хочу получать багфиксы/новые фичи автоматически при обновлении, не копаясь при этом в двухзначном числе зависимостей (если добавить туда ещё дерево зависимостей, то может получится число трехзначное) и читая историю обновлений каждой из них, в попытке понять что там поменялось. Если бы в npm/composer не использовался semver, то я представляю сколько человеко-часов тратилось бы каждым разработчиком каждого пакета на вычитку изменений в каждой зависимости. Люди бы годами не подтягивали обновления зависимостей с правками багов и все превратилось бы в болото. Возьмите любой популярный фреймворк на js (React, Vue, Angular) или PHP фреймворк (Laravel, Symfony) — все они следуют semver и я спокойно в своих проектах могу их обновлять с закрытыми глазами.

Semver нужен разработчикам, которые пишут и используют библиотеки или фреймворки. Если посмотреть на любой современный фреймворк или крупную библиотеку на том же PHP, все они используют массу других библиотек. При этом какая-то популярная библиотека может использоваться десятком других библиотек. Системы управления версиями типа composer позволяют вычислить, какие версии чего надо установить, чтобы вся система работала. Без semver-а было бы непонятно, как вычислить такое пересечение.

Для конечного пользователя продутка типа Эгеи или, там, Гугл Хрома это все, разумеется, не имеет особого значения.

Евгений Лазарев, для проекта — да, конечно, зависимости надо четко фиксировать. А вот для библиотеки — нет.

Konstantin Baryshnikov, а в чём отличие библиотеки от проекта?

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

Отличие библиотеки от проекта в том, что библиотека не является конечным продуктом для пользователя, а предназначена для использования программистом в других проектах или библиотеках. Одна и та же библиотека может быть использована десятками других библиотек, которые используются в одном и том же проекте. И если везде привязаться к конкретной версии, то в случае несовпадения даже patchlevel-версии возникает конфликт при разрешении дерева зависимостей (сведения его к списку конкретных версий устанавливаемых библиотек). Semver же позволяет этот вопрос разумно решить: если библиотека X требует библиотеку A версий 2.*.*, а библиотека Y требует ту же библиотеку A версии 2.3.*, то очевидно, что можно установить A версии 2.3.последняя.

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

Konstantin Baryshnikov, мне кажется неверным предположение, что библиотека не является продуктом. Всё — продукт. Программист тоже пользователь. Описание системы разруливания конфликтов выглядит хорошо, но на практике мы имеем что имеем — всё упирается в предположение о том, что разработчик библиотеки ничего не сломает даже минорным патчем. А это ну такое себе предположение для большинства проектов :—) Уверен, что в крупных значимых проектах, где десятки зависимостей, всё равно все зависимости проходят ручной контроль, а для мелких проблема решения конфликтов неактуальна. Короче, система получается бессмысленной и нежизнеспособной.

Если каждая версия библиотеки будет фиксировать конкретные версии других библиотек, то конфликт версий возникнет моментально. В javascript — там, да, можно установить сразу несколько версий, ведь JS-модули просто экспортируют объекты. А в тех же PHP или Java библиотеки регистрируют глобальные классы в глобальных неймспейсах, и две версии сразу использовать невозможно. Так что такая система будет просто нежизнеспособной — вообще ничего работать не будет.

На уровне проекта же в lock-файлах фиксируются все версии (не только напрямую используемых библиотек, но и всех их зависимостей).

Konstantin Baryshnikov, всё прекрасно будет работать, но немного в другой парадигме. Например, разрешать публичное распространение даже минорного апдейта у пакета только после одобрения несколькими сторонними код-ревьюерами, для которых этот пакет приносит пользу. Таким образом, апдейты будут выходить реже, но они будут качественнее, и вот тогда уже можно ставить ^. А сейчас ^ можно ставить только у нескольких крупнейших проектов, у остальных по умолчанию должно быть строгое фиксирование версии и ручное разруливание конфликтов версий.

Просто вы вроде не поддерживаете семвер, но Эгея у вас 2.9, но при этом промежуточные версии — это сборки v3543, v3387.
Это по сути и есть семвер.

Евгений, это сработает в рамках единой организации, но кто же будет ходить за чьим-то одобрением в мире опенсорса, в котором разработка ведется по «базарному» принципу (см. Eric S. Raymond, The Cathedral & the Bazaar) огромным количеством независимых разработчиков? Тут все строится на репутации, за качеством кода, покрытием тестами и отсутствием регрессий в действительно популярных и востребованных пакетах следят.

Бесконечно можно смотреть на три вещи: как горит огонь, как течёт вода и как дизайнеры объясняют программистам почему они всё делают неправильно.

Гоша, вы так говорите, как будто это что-то плохое. Такие обсуждения важны, они вскрывают суть вещей, о которой забывают, делая все по привычке.

Илье для Эгеи semver нафиг не нужен, и в этом контексте его рассуждения логичны. А вот для той же системы поиска (забыл название), которая внутри Эгеи используется, в semver-е есть определенная польза.