Underscore: Подчеркивание не следует за SemVer

Чтобы процитировать https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249:

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

Остальную часть комментария тоже стоит прочитать, даже если вы не согласны.

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211 тоже

@ akre54 Мне любопытно, что вы думаете о том, что другие проекты, такие как Lo-Dash (альтернатива Underscore) и ExosJS (альтернатива Backbone), могут следовать за semver?

Поскольку эти вставные замены _могут следовать за semver_, не бросает ли это гаечный ключ оправдание, продвигаемое ядром Underscore/Backbone?

Пара вещей.

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

Lo-Dash добавляет гораздо больше защитного кода для bc за счет беспорядка в коде, в то время как Underscore стремится к лаконичности. Легче обойтись несколькими дополнительными строками кода, когда библиотека изначально больше (Lo-Dash работает с 8,7 тыс. строк против 1,4 тыс. для Underscore). Dash, так как большая часть логики является внутренней.

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

Как ни странно, я чувствую, что Underscore также имеет недостаток графика выпуска, поскольку используется во многих других проектах для начинающих, чем Lo-Dash (по самой своей природе Lo-Dash имеет тенденцию обращаться к разработчикам, которым нужна его мощь). Более продвинутому разработчику будет удобнее иметь дело с последствиями критических изменений, и он может немного лучше понять их аргументацию.

Наконец, как соавтор и ведущий участник Exoskeleton, я буду первым, кто скажет вам, что мы тоже не следили за semver. У нас также есть преимущества Lo-Dash, как описано выше.

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

Какое это имеет отношение к стратегии версий Underscore? Lo-Dash обновляет версии после semver, поэтому версия 2.x переходит на версию 3.x.

Lo-Dash добавляет гораздо больше защитного кода для bc за счет беспорядка в коде, в то время как Underscore стремится к лаконичности.

Какое отношение защитный код или лаконичность имеют к стратегии версий?

Легче уйти с несколькими дополнительными строками кода, когда библиотека изначально больше (Lo-Dash показывает 8,7 тыс. строк против 1,4 тыс. для Underscore).

У Lo-Dash есть встроенные документы, LOC не имеет отношения к управлению версиями.

В Lo-Dash также можно сделать гораздо больше внутренних ошибок, поскольку большая часть логики является внутренней.

Нельзя ли то же самое сказать о Underscore?

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

Вот почему у Underscore есть сопровождающие, которые могут принять/отклонить или отложить до будущего выпуска.
Опять же, не относится к версии.

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

Я не согласен, у Lo-Dash тысячи иждивенцев, и все не могут быть в этом экспертами.

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

Поскольку Lo-Dash следует за semver, разработчикам не приходится иметь дело с последствиями, пока они не перейдут к обновлению основной версии. В отличие от Underscore, Lo-Dash не изменится из-под ног, потому что они использовали ~ для диапазона версий пакета.

Наконец, как соавтор и ведущий участник Exoskeleton, я буду первым, кто скажет вам, что мы тоже не следили за semver.

Тогда вы должны удалить это из своего маркетинга.

Я не думаю, что есть какая-то причина, по которой Underscore не мог подписаться на semver.
Не следовать этому - плохая услуга для ваших пользователей :frowning:

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

Мы говорим о выборе, который нарушает производственный код. Нехорошо играть в небрежную игру с чужим временем и деньгами.

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

+1 за несколько месяцев

Лично я не считаю "крутым" указывать _personal_ в отчете об ошибке. Либо это соответствует, либо не соответствует семантическому управлению версиями. Вот причины — бах, бах, бах — почему это была бы еще лучшая библиотека, если бы она это сделала. Вот причины — бах, бах — почему сопровождающие могут увеличивать номер версии способом, соответствующим semver.

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

Но давайте попробуем иметь гражданское несогласие.

Я не понимаю @raganwald. Кто переходит на личности?

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

Если вы нарушите этот контракт, вы нарушите код других людей. Это не круто.

npm работает очень хорошо, потому что мы все согласны с несколькими правилами, благодаря которым наши модули хорошо работают друг с другом. Если вы нарушите эти правила, вы нарушите другие модули, которые пытаются работать с вашими. Вы ломаете рабочие приложения, которые полагаются на ваш код.

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

Ключевым моментом является то, что в таком проекте, как Underscore, _каждое_ изменение кому-то мешает. Если мы удалим нулевую защиту из _.extend (используя случайный пример), потому что она вызывает ошибку у кого-то и создает ошибку у кого-то другого, будет ли это патчем? Это минорная версия? Главный?

Для Underscore и Backbone я не думаю, что неразумно закреплять ваши зависимости. Следование semver не является обязательным требованием для публикации в упаковщике.

Ключевым моментом является то, что в таком проекте, как Underscore, каждое изменение кого-то ломает.

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

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

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

Для Underscore и Backbone я не думаю, что неразумно закреплять ваши зависимости.

В документации обязательно должно быть сообщение/предупреждение.

@akre54 Изменение _недокументированных_ функций или _недокументированных ошибок_ может привести к поломке кода, основанного на них, но пользователи полагаются на недокументированные функции и ошибки на свой страх и риск.

Игнорирование semver подвергает опасности _каждого_ пользователя_ вашего API. Люди постоянно исправляют ошибки в больших проектах с открытым исходным кодом, которые следуют за semver, но _очень редко можно увидеть большие номера версий в экосистеме npm_.

Почему это?

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

Чтобы добавить к анекдотам, мой код также был сломан ударами Underscore в прошлом. Мы прибегли к фиксации node_modules , чтобы предотвратить это, потому что --save --save-exact не работает. Если зависимость второго уровня опирается на Underscore и использует версию ^x.y.z , ваше приложение по-прежнему не работает.

Что касается номеров версий, указывающих прогресс, меня это не волнует. Использование версии 2.1.3 или 143.3.2 для меня не имеет значения. Прогресс и зрелость библиотеки не измеряются номерами версий. Я просто не хочу звонить в воскресенье днем ​​из-за того, что кто-то обновил зависимость, основанную на underscore@^x.y.z .

:thumbup: Ага. @braddunbar делает вывод, до которого я еще не дошел - игнорирование semver делает ваш пакет опасным, опасным пакетом, потому что это критическое изменение может задерживаться _где угодно_.

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

ИМО, настоящий прогресс и зрелость библиотеки измеряется надежностью, и semver имеет большое значение для достижения этой цели.

В документации обязательно должно быть сообщение.

Определенно. Я рад добавить один, если мы так решим.

Я не против лучшей системы релизов (господи знает, как мучительно месяцами ждать, пока ваше маленькое исправление будет развернуто), но я не уверен, что «следовать за семвером» — это единственный правильный ответ.

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

Я не думаю, что кто-то сказал, что «следуй за семвером» — единственный правильный ответ для лучшей системы выпуска. Мы сказали, что это контракт API npm, и нарушение этого контракта наносит ущерб.

@jdalton и @dilvie Как бы вы предложили обрабатывать релизы? Как насчет принятия функций? «Использовать семвер» на самом деле ничего нам не говорит.

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

Я думаю, что слово semver здесь не совсем применимо.

Бесстыдная самореклама: используйте следующее обновление https://github.com/bahmutov/next-update , чтобы сначала проверить, можно ли обновить зависимости, не нарушая ваш проект. Я постоянно находил критические изменения в разных модулях несмотря на измененные *.*.x , так что теперь я не доверяю никаким самопровозглашенным версиям.

Думаете, этот проект — снежинка? Lo-Dash — это, по сути, Underscore++, и следование semver не представляет проблемы для @jdalton.

Принятие новых функций:

Нарушает ли это существующий контракт API?

Да? - увеличить основной номер версии.
Нет? - увеличить номер минорной версии.

Принятие исправлений ошибок / незначительных исправлений:

Нарушает ли это существующий контракт API?

Да? - увеличить основной номер версии.
Нет? - номер версии бамп-патча.

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

Согласен с @dilvie , например, https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 , вероятно, должен был стать серьезным ударом, поскольку мы отказались от поддержки разреженных массивов. Следующая версия должна быть серьезной, так как мы добавим тонну нового сахара через lookupIterator и откажемся от нативных итераторов.

Если документация функции должна измениться, это явно серьезное изменение.

В этом году я кратко обсудил это на JSconf. У меня нет времени вдаваться в подробности здесь, но:

прекратите смешивать ориентированное на человека «управление версиями» с «совместимостью с API» для компьютера (или, на самом деле, для системы сборки). просто остановись.

Версия: «Эта вещь, которая мне нравится, имеет новые функции или что-то еще, что меня должно заинтересовать, когда у меня будет время». Есть новый айфон. Есть новая OS X. Есть новый Ember. Есть новый пересмотренный отчет о схеме алгоритмического языка.

Совместимость API: «Эта вещь была обновлена, чтобы исправитьпроблема, и это может/сломает путьупражняет эту штуку». Вилка питания iPhone была заменена. Вилки ресурсов OS X устарели. Ember отказался от стиля имен действий. Схема теперь чувствительна к регистру.

Последнее происходит _во время_ или _наряду_ с первым; но первое никоим образом не обязательно зависит от второго или даже связано с ним. Они должны отслеживаться и (если мы действительно собираемся _указать_ систему управления версиями, господи) указываться отдельно. (концепция «семантического управления версиями», популярная в сообществе JS, _особенно_ тупая и ужасная; но опять же, я не хочу подробно вдаваться в чью-то ветку комментариев к выпуску.)

Вкратце: они не портят вашу экосистему, выбирая собственный путь. (Особенно, когда этот путь ужасно ошибочен.) Я бы хотел, чтобы таких проектов было больше. Иди используй что-нибудь другое, если ты так не в форме из-за этого.

@elliottcable - согласился с тем, что лицо человека отличается от лица компьютера ... Пока человеческое лицо не похоже на лицо компьютера, так что объединение менее проблематично.

Может быть, назовем следующий релиз, посвященный человеческому движению, как-то вроде «снежинка» вместо nnn.

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

Нарушает ли это существующий контракт API?

Вспомните самые первые аргументы в этой ветке. «Все в Underscore — это, по сути, площадь поверхности», следовательно, все, задокументированное и нет, является частью его контракта API. Любое изменение — это изменение для всех.

Lo-Dash, будучи «Underscore++», не имеет дело с почти таким количеством изменений в функциях, потому что он может безопасно следовать за Underscore в разработке основных функций. Улучшения Lo-Dash в основном заключаются под капотом или в добавлении нескольких методов, а не в принципиальном переосмыслении его функций.

@akre54

Как бы вы предложили обрабатывать релизы? Как насчет принятия функций? «Использовать семвер» на самом деле ничего нам не говорит.

Вы можете принять новый API или даже некоторые улучшения существующего API. Если вы добавляете новый API или улучшения (которые не нарушают совместимость), это обновление второстепенной версии.

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

Я думаю, что _.matches довольно прямолинеен. Всегда будут исправления ошибок.

Я думаю, что слово semver здесь не совсем применимо.

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

@dilvie : собираюсь держаться подальше от остальной части аргумента, но добавлю это: очень, очень нравится ваше предложение придерживаться соглашения «имя версии». знак равно

Что касается части, ориентированной на человека, я большой поклонник версионирования в стиле less :

> less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

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

+1 за подчеркивание 42: «Глупая Шелти».

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

@akre54

Lo-Dash, будучи «Underscore++», не имеет дело с почти таким количеством изменений в функциях, потому что он может безопасно следовать за Underscore в разработке основных функций.

Что это хотя бы значит? Lo-Dash имеет дело с _большими изменениями_ и следует собственной версии, отличной от Underscore. Lo-Dash изменился так сильно, что ему пришлось предложить сборку, совместимую с Underscore, чтобы продолжить поддержку замены. У нас разные функции , методы и разные проблемы с совместимостью API.

Улучшения Lo-Dash в основном заключаются под капотом или в добавлении нескольких методов, а не в принципиальном переосмыслении его функций.

Это тоже не так. Lo-Dash движется быстрее и чаще сталкивается с ударами сзади. Вот почему мы переходим от ~v2.x к ~v3.x. Lo-Dash похож на Underscore. Если Lo-Dash может следовать за semver, то может и Underscore. Делаю уже ~2 года. Ваши доводы просто терпят крах перед лицом реальности.

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

Мне любопытно, как все думают, что следует определять «критическое изменение». _Каждое_ изменение новой функции в Underscore является критическим изменением для кого-то еще.

Возьмем, к примеру, все последние изменения в _.each . Должны ли мы столкнуться с изменением возвращаемого значения _.each , чтобы вернуть исходный список ? Это исправление? Новая функция? Обратно несовместимое изменение? Раньше он возвращал undefined , так что вряд ли он сломал чей-то код.

Должны ли мы столкнуться, когда позволим внутреннему помощнику each быть переназначенным извне ? Могло ли это взломать чей-то код? Публичный API там не изменился.

Изменение _.each , чтобы избежать разреженных массивов , и использование циклов for вместо нативных forEach , очевидно, для некоторых не работает, но поскольку разреженные массивы мертвы , кого это действительно волнует? Это то, что мы должны протолкнуть основную версию? Это исправление?

Я думаю, что мы запоздали с обновлением основной версии (многое произошло за 219 коммитов ). Выпуск версии 2.0 и укрепление нашей политики версий имели бы здесь большое значение.

@akre54

Каждое новое изменение функции в Underscore является критическим изменением для кого-то еще.

Не обязательно.

Возьмем, к примеру, все последние изменения в _.each. Должны ли мы столкнуться с изменением возвращаемого значения _.each, чтобы вернуть исходный список? Это исправление?

Это не исправление ошибки, это улучшение. Является ли это неразрушающим? -- Вероятно, это безопасное изменение, потому что маловероятно, что возвращаемое значение _.each полагалось, а не то, что разработчики сообщили как препятствие при переходе на Lo-Dash. Если вы сомневаетесь, встаньте на сторону взлома или проверьте воду с выпуском RC. Если бы изменение заключалось в том, чтобы разрешить ранний выход из _.each , я бы сказал, что это определенно критическое изменение, поскольку разработчики сталкиваются с этим при использовании CoffeeScript.

Должны ли мы столкнуться с тем, что позволили внутреннему каждому помощнику быть переназначенным извне? Могло ли это взломать чей-то код? Публичный API там не изменился.

Я бы сказал, что это относится к недокументированным деталям реализации. В то время изменение не позволяло ничего нового, потому что Underscore все еще разветвлялся на нативные методы. Это изменение подпадает под большую группу изменений в версии 1.6.0, поэтому может появиться в версии 2.0.

Изменение _.each , чтобы избежать разреженных массивов, и использование циклов for вместо нативных forEach , очевидно, для некоторых не работает, но раз разреженные массивы мертвы, кого это действительно волнует? Это то, что мы должны протолкнуть основную версию? Это исправление?

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

Я думаю, что мы запоздали с обновлением основной версии (многое произошло за 219 коммитов). Выпуск версии 2.0 и укрепление нашей политики версий имели бы здесь большое значение.

:+1:

критические изменения (множественное число критических изменений)

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

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

Таким образом, добавление любого свойства или метода в API, как правило, не является критическим изменением (API открыт для расширения, но закрыт для обратно несовместимых изменений).

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

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

Была ли это задокументированная функция API, которая служила какой-то цели? Например, некоторые функции возвращают неопределенное значение, когда переданные входные данные не приводят к осмысленному выводу. С each похоже дело обстоит иначе... Так что, наверное, не ломается.

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

Разреженные массивы могут не пережить ES6, но они еще не умерли.

@akre54
Иногда ответ на вопрос, ломается изменение или нет, не является прямым. В таких случаях помогают контекст, история и данные. К счастью, я смог использовать Lo-Dash в качестве полигона для тестирования новых функций и посмотреть, какие изменения сбивают с толку разработчиков, поступающих от Underscore. Underscore, в свою очередь, может использовать это для принятия обоснованных решений о влиянии изменений.

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

@jdalton , классный поступок. :)