Backbone: Следуйте за SemVer

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

Если бы мы строго следовали «семантическому» управлению версиями, к настоящему времени это, вероятно, был бы Backbone.js 43.0.0 , что не помогает никому оценивать фактический прогресс проекта.

Итак, как я люблю шутить - не "семантическое" управление версиями, _романтическое управление версиями_.

Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте:

ОСНОВНАЯ версия, когда вы делаете крупный новый выпуск или значительно обновляете и / или стабилизируете API.
МИНИМАЛЬНАЯ версия при добавлении незначительных новых функций.
Версия PATCH, когда вы вносите крошечные изменения, скорее всего, останется незамеченной большинством.

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

Но избегать любых изменений в API и ждать, пока будет готов «ГЛАВНЫЙ» выпуск, было бы огромным препятствием для прогресса. И альтернатива частому увеличению номера ОСНОВНОЙ версии невероятно бесполезна.

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

В чем проблема с Backbone 43.0.0?

• Отправлено из Chrome 32.0.1700

+1 за spadgos @ вопрос. Номера версий произвольные. По какой-то причине у нас есть гибкие веб-приложения, которые пытаются работать в тех же диапазонах, что и операционные системы. Многие приложения боятся выхода за пределы 10 ... но большинство проектов, которые вы моделируете (Windows, Linux и т. Д.), Имеют цикл разработки один / несколько лет перед выпуском, поэтому 1.x -> 2.x это большое дело. Agile-проект развивается очень быстро, также имеет смысл быстрое наращивание.

Я также не согласен с обоснованием этого.

Прямо сейчас Marionette находится на версии 1.2.3 и старается соблюдать строгую семантическую версию. Пока у нас не было никаких проблем, хотя мы тоже «все на поверхности». Мы добавили новые функции. Мы исправили ошибки. Но версия 1.0 по-прежнему совместима с версией 1.2.3. Мы отложили билеты на выпуск версии 2, если они представляют собой изменения API или ожидаемые изменения поведения.

Крупные выпуски с критическими изменениями не обязательно должны происходить каждую неделю, когда принимается запрос на перенос. Их можно (и нужно) объединить в основной выпуск, который включает в себя достаточную ценность для большого выпуска с повышением основной версии.

В нынешнем виде нарушение совместимости в выпуске v1.1 причиняет много боли разработчикам плагинов и надстроек, таким как команда MarionetteJS. Нам пришлось заменить поведение патчами в нашем коде, чтобы мы могли оставаться жизнеспособными как для v1.0, так и для v1.1 ... это неприятная ситуация. Эффект пульсации базовой библиотеки, такой как Backbone, с критическими изменениями, огромен ... затронут не только Backbone.

Я согласен, это больше похоже на «не хочу», а не на «не могу». Критические изменения, такие как https://github.com/jashkenas/backbone/pull/2461 , не имеют реального смысла срочности и, возможно, нужно было дождаться обновления основной версии, если вам не нужна проблема 43.0.1.

Для меня самая большая проблема с Backbone, не уважающим semver (среди прочего), заключается в обучении и пропаганде Backbone. Нехорошо говорить группе студентов или потенциальных клиентов, что все в вашем стеке будет работать определенным образом ... кроме Backbone.

При «проповедовании» Backbone всегда было два серьезных предостережения: это не AMD из коробки, и она не уважает SemVer, поэтому не относитесь серьезно к номерам версий. Один из них исправлен. Исправим другое.

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

@jashkenas, мы всегда могли оставить третью цифру на .0 :)

Это, вероятно, будет семантически отображено на SemVer немного ближе, чем то, что мы делаем сейчас. Возможно, это ослабит некоторые пассивно-агрессивные крипто-политические замечания о том, что почему-то технически неправильно не следовать за СемВером.

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

ps Я не имел в виду, что проблема @keithamus является пассивно-агрессивной, и мне очень жаль, если это так и произошло. Совершенно законно обсуждать, как Backbone сообщает пользователям об изменениях.

: +1: для семвера. Меня в первую очередь интересует версия данного программного обеспечения не как показатель его прогресса, а как показатель совместимости.

Как правило, после 1.0 (когда я ожидал, что все будет в основном стабильным и работающим), номера версий в значительной степени бессмысленны как индикаторы прогресса. Программное обеспечение X в версии 10 может быть гораздо менее зрелым, иметь меньше функций, чем Программное обеспечение Y в версии 2. Если вы хотите знать о прогрессе части программного обеспечения, вы должны посмотреть его журнал изменений или дорожную карту.

Знание того, что Backbone (или что-то еще) имеет версию 2.4.3, ничего не значит с точки зрения его возможностей. Однако это _должно_ означать, что я могу обновиться со своей версии 2.0.4 без каких-либо поломок.

Если бы мы строго следовали «семантическому» управлению версиями, то, вероятно, к настоящему времени это был бы Backbone.js 43.0.0, что не помогает никому оценивать фактический прогресс проекта.

Очень незначительная проблема или ее отсутствие. Не следите за семвером? Большая проблема.

: +1:, семвер просто необходим для такого большого проекта.

Я с @knowtheory. 43.0.0 выглядит немного странно, но я думаю, что 1.43.0 будет в порядке, и никто не получит неожиданной поломки после npm install .

Кого волнует большое количество версий?
Это стандарт, если вы можете его использовать, вы должны его использовать.
Я даже не понимаю, почему эта дискуссия длится так долго.

: +1: Это предотвратило бы некоторые проблемы в # 2996 и # 2997, а также проблемы, которые возникали у других с несколькими другими выпусками Backbone.

@braddunbar, который (и остальные причины «против») звучит так, как будто он ценит эстетику номера версии над его фактическим значением.

Спасибо, но строгое следование «семантическому» управлению версиями не сработает для Backbone.

Я думаю, что это больше связано с тем, что Backbone хорошо работает для своих пользователей (с управлением зависимостями). Какой следующий семвер гарантирует…

Более частые выпуски помогли бы быстрее выявлять ошибки Showstopper. Я думаю, что это слишком много - просить людей постоянно запускать пограничные версии Backbone только для исправления ошибок, которые им нужны.

+1 @derickbailey

Так же, как пример, начиная с версии 1.1.0, идея выпусков исправлений заключается в том, что эти исправления не нужны вообще.

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

Для пакетов в npm или bower это даже не обсуждается.

Когда вы публикуете пакет с помощью npm или bower, semver является частью контракта API, который вы заключаете. Когда вы нарушаете этот контракт, вы нарушаете другие модули, которые зависят от вашего. Вы нарушаете производственный код, который зависит от вашего модуля.

Вопрос не в том, "стоит ли нам использовать semver?" Вопрос в том, хотим ли мы быть хорошими гражданами в экосистеме?

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

Когда вы публикуете пакет с помощью npm или bower, semver является частью контракта API, который вы заключаете.

Нет, это не так. npm install --save [email protected] не является обременительным требованием.

@ akre54 Мне интересно ваше мнение о семвере. Я знаю, что думает @jashkenas, но какие ваши.

@ akre54 Да, это так. npm предполагает, что все пакеты в репозитории следуют за semver . Так он определяет, какие пакеты с какими совместимы.

Из документа package.json :

«Версия должна быть проанализирована с помощью node-semver, который связан с npm в качестве зависимости. (Npm install semver, чтобы использовать его самостоятельно.)»

Если ваши номера версий _lie_, когда они интерпретируются как semver, это неправильный синтаксический анализ. Таким образом, вы нарушаете package.json и нарушаете совместимость с тем, как люди используют версии пакетов в экосистеме npm.

Это не просто вопрос личных предпочтений. Это вопрос совместимости пакетов.

Можно ли заставить ваш пакет работать нормально, если он не использует semver? _Sure_, это так, но если вы не называете это громко и смело в верхней части вашего readme - немногие пользователи будут знать, что это необходимо, и когда вы вводите критическое изменение, их код может очень легко сломаться.

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

npm install --save [email protected] не является обременительным требованием.

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

Есть очень веские причины следовать за семвером. «Номер моего пакета может стать действительно большим» - ужасная причина _не_ использовать semver. Отслеживание прогресса вашего приложения - далекая вторая причина для версий пакетов. Самая важная функция версии - знать, «будет ли эта версия работать с моим приложением?»

Кстати, если номер вашей посылки станет действительно большим, возможно, это запах кода. Вам нужно только поднять основную версию, когда вы вносите _безопасное изменение_. Критическое изменение по определению - это такое изменение, которое нарушает принцип открытости / закрытости. Открыт для продления, закрыт для критических изменений. Все хорошие API-интерфейсы следуют принципу открытого / закрытого настолько точно, насколько это возможно, чтобы пользователи могли идти в ногу с API, а изменения не нарушали существующий код.

Я думаю, что усвоенный здесь урок заключается в следующем: «Не используйте ~ или ^ при загрузке Backbone через package.json»

@ akre54 Мне интересно ваше мнение о семвере

В общем, я согласен с приведенными здесь аргументами, но мне действительно нужно задаться вопросом, является ли изменение основной версии лучшим курсом действий для каждого критического изменения (и, опять же, с Underscore, в основном поверхностной областью, это очень много). Underscore используется во многих сторонних библиотеках, и требовать, чтобы все они не отставали от огромных версий, было бы обременительно и опасно. (Должен ли выпущенный сегодня пакет зависеть от Underscore до версии 2? 1.7? 1.6.x? Должен ли он закреплять свои зависимости за счет, возможно, необходимости отдельного Underscore от основного проекта?)

Я думаю, что усвоенный здесь урок заключается в том, что "не используйте ~ или ^ при загрузке Backbone через package.json"

Ага.

Я думаю, что усвоенный здесь урок заключается в том, что "не используйте ~ или ^ при загрузке Backbone через package.json"

Я изложил выше, почему это не должно быть уроком на вынос.

Я думаю, что усвоенный здесь урок заключается в том, что "не используйте ~ или ^ при загрузке Backbone через package.json"

Как следствие, это то, что вы делаете, чтобы защитить свой код от взлома.

Урок был бы больше похож на «следующее семвер хорошо для всех, а не делать этого - нет».

Я понимаю ценность «романтического» управления версиями. Жаль, что они не очень хорошо сосуществуют.

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

По крайней мере, Backbone в целом умеет ничего не ломать.

@dgbeck все время ломается по версиям, см. мой предыдущий комментарий

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

Для меня это большой плюс, но, очевидно, это происходит за счет сложности для сопровождающего.