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（アンダースコアの代替）やExosJS（バックボーンの代替）のような他のプロジェクトがsemverに続くことができるという事実について、あなたの考えはどうですか？

これらのドロップイン置換は_semverに続くことができる_ので、アンダースコア/バックボーンコアによってプッシュされた言い訳にそのような種類のレンチを投げませんか？

カップルのもの。

Lo-Dashは、ほとんどの場合、Underscoreによって舗装されたカウパスに固執するため、Underscoreがリリースされるまで保留して、機能の同等性のためにバージョンバンプをプッシュするという利点があります。 アンダースコアとの違いは、機能強化のカテゴリでより多く、重要な重大な変更ではより少ない傾向があります。

Lo-Dashは、コードの乱雑さを犠牲にしてbcにはるかに多くのガードコードを追加しますが、Underscoreは簡潔さを追求します。 ライブラリが最初から大きい場合は、数行の余分なコードを使用する方が簡単です（Lo-Dashは8.7k行であるのに対し、アンダースコアは1.4kです）。Lo-で実行できる内部マッキングもはるかに多くあります。ロジックの多くは内部にあるため、ダッシュします。

また、 1人の寄稿者（あなた）によって不釣り合いに書かれていますが、Underscoreの変更は、はるかに多様な寄稿者のセットから行われる傾向があります。つまり、新しい機能はいつでも提供される可能性があり、大きな機能の変更や後方互換性のない変更は、リリーススケジュール。

ちなみに、Underscoreには、Lo-Dashよりも多くの初心者プロジェクトで使用されるというリリーススケジュールの欠点もあると感じています（Lo-Dashは、その性質上、そのパワーを必要とする開発者にアピールする傾向があります）。 より高度な開発者は、変更を壊すことによるフォールアウトに対処するのがより快適になり、彼らの推論をもう少し理解するかもしれません。

最後に、Exoskeletonの共著者兼主な寄稿者として、私もsemverをフォローしていないことを最初にお知らせします。 上記のように、Lo-Dashの利点もあります。

Lo-Dashは、ほとんどの場合、Underscoreによって舗装されたカウパスに固執するため、Underscoreがリリースされるまで保留して、機能の同等性のためにバージョンバンプをプッシュするという利点があります。 アンダースコアとの違いは、機能強化のカテゴリでより多く、重要な重大な変更ではより少ない傾向があります。

それはUnderscoreのバージョン戦略と何の関係がありますか？ Lo-Dashは、semverに続いてバージョンをバンプします。これが、v2.xでv3.xに移行する理由です。

Lo-Dashは、コードの乱雑さを犠牲にしてbcにはるかに多くのガードコードを追加しますが、Underscoreは簡潔さを追求します。

ガードコードまたは簡潔であることは、バージョン戦略と何の関係がありますか？

ライブラリが最初から大きい場合は、数行の余分なコードを使用する方が簡単です（Lo-Dashクロックは8.7k行であるのに対し、アンダースコアは1.4kです）。

Lo-Dashにはインラインドキュメントがあり、LOCはバージョン管理とは関係ありません。

ロジックの多くは内部であるため、Lo-Dashで実行できる内部マッキングもはるかに多くあります。

アンダースコアについても同じことが言えませんか？

また、1人の寄稿者（あなた）によって不釣り合いに書かれていますが、Underscoreの変更は、はるかに多様な寄稿者のセットから行われる傾向があります。つまり、新しい機能はいつでも提供される可能性があり、大きな機能の変更や後方互換性のない変更は、リリーススケジュール。

そのため、Underscoreには、将来のリリースまで承認/拒否または延期するメンテナがいます。
繰り返しますが、バージョン管理には関係ありません。

ちなみに、アンダースコアには、Lo-Dashよりも多くの初心者プロジェクトで使用されるという欠点もあるように感じます（Lo-Dashは、その性質上、その力を必要とする開発者にアピールする傾向があります）。

私は同意しません、Lo-Dashには何千もの扶養家族がいて、すべてがそれの専門家になることはできません。

より高度な開発者は、変更を壊すことによるフォールアウトに対処するのがより快適になり、彼らの推論をもう少し理解するかもしれません。

Lo-Dashはsemverに従うため、開発者はメジャーバージョンの更新にジャンプするまでフォールアウトに対処する必要はありません。 アンダースコアとは異なり、Lo-Dashはパッケージのバージョン範囲に~を使用しているため、足元から変更されません。

最後に、Exoskeletonの共著者兼主な寄稿者として、私もsemverをフォローしていないことを最初にお知らせします。

次に、それをマーケティングから削除する必要があります。

アンダースコアがsemverをフォローできなかった理由はないと思います。
これに従わないことは、ユーザーにとって不利益です：しかめっ面：

npmやbowerに参加したいのなら、議論の余地はありません。 semverを使用する必要があります。 あなたはsemverに従うという暗黙の約束をしているのですが、そうしないと、警告なしに人々のコードが壊れてしまい、ほとんどの人が眉をひそめています。

私たちは、プロダクションコードを壊す選択について話している。 他の人の時間とお金でずさんなゲームをするのはクールではありません。

つまり、バージョン番号が速く大きくなります。 だから何？ それは数です。 これは、誰かの生産ショッピングカートを壊すよりもはるかに優れています。

semverの+1

個人的には、バグレポートで_personal_を取得するのは「クール」ではないと思います。 セマンティックバージョニングに従うか、従わないかのどちらかです。 理由は次のとおりです。バング、バング、バング-もしそうなら、それがさらに優れたライブラリになる理由です。 メンテナがsemverと一致する方法でバージョン番号をインクリメントすることが可能である理由（bang、bang）は次のとおりです。

その後、それはメンテナ次第です。 彼らの立場に同意できない場合は、使用する代替ライブラリがあります。プロジェクトをフォークすることができます（他の人が行ったように）。 あなたは好きなだけ個人的になるブログ投稿を書くことができます。

しかし、市民の意見の不一致を試してみましょう。

@raganwaldがわかりません。 誰が個人的になりますか？

私は誰も攻撃していません。 semverは、npmまたはbowerにパッケージを公開するときに締結するAPIコントラクトの一部であることを指摘しています。

その契約を破ると、他の人のコードを破ることになります。 それはクールではない。

npmは、モジュールが互いにうまく機能し続けるためのいくつかのルールに全員が同意しているため、非常にうまく機能します。 これらのルールに違反すると、自分のルールを使用しようとする他のモジュールに違反します。 コードに依存する本番アプリを壊します。

問題は「semverを使うべきか」ではありません。 問題は、「このエコシステムで良き市民になりたいのか」ということです。

重要な点は、アンダースコアのようなプロジェクトでは、_すべての_変更が誰かに影響を及ぼしているということです。 誰かにバグを引き起こし、他の誰かにバグを作成するために（ランダムな例を使用するために） _.extendからヌルガードを削除した場合、それはパッチですか？ それはマイナーバージョンですか？ 選考科目？

アンダースコアとバックボーンの場合、依存関係を固定するのは不合理ではないと思います。 次のsemverは、パッケージャーに公開するための要件ではありません。

重要な点は、アンダースコアのようなプロジェクトでは、すべての変更が誰かに影響を及ぼしているということです。

あなたは自分の立場を正当化するために極端にジャンプしています。 現実はそれがバランスです。 人気のあるAPI、エッジケース、および文書化された動作があります。 バグを修正して機能を追加するだけで、メジャーバージョンにぶつかることなく長時間使用することができます。

それが意味するのは、メンテナが考え、計画しなければならないということです。 これは、バックコンパットを壊さずに取り組むことができない機能や変更のロードマップを作成する必要があるかもしれないことを意味し、それは問題ありません。

アンダースコアはパッチリリースを強化し、重大な変更を導入しました。 これは、メンテナが完全に制御できるものです。

アンダースコアとバックボーンの場合、依存関係を固定するのは不合理ではないと思います。

確かにドキュメントにメッセージ/警告があるはずです。

@ akre54 _undocumented_機能または_undocumentedバグ_を変更すると、それらに依存するコードが破損する可能性がありますが、ユーザーは自分の危険で文書化されていない機能とバグに依存します。

semverを無視すると、APIの_すべてのユーザー_が危険にさらされます。 人々は常にsemverに続く大規模なオープンソースプロジェクトのバグを修正しますが、_npmエコシステムで大きなバージョン番号が表示されることは非常にまれです_。

何故ですか？

_すべての優れたAPIはオープン/クローズド原則_（拡張のためにオープン、変更を中断するためにクローズ）にできるだけ厳密に従うため、ユーザーはAPIに遅れずについていくことができ、変更によって既存のコードが中断されることはありません。

逸話に追加するために、私のコードも過去にアンダースコアのバンプによって壊れています。 --save --save-exactはそれをカットしないので、それを防ぐためにnode_modulesをコミットすることに頼りました。 第2レベルの依存関係がアンダースコアに依存し、 ^x.y.zバージョンを使用している場合、アプリはまだ壊れています。

進捗状況を示すバージョン番号は気にしません。 バージョン2.1.3または143.3.2を使用しても、私には何の違いもありません。 ライブラリの進行状況と成熟度は、バージョン番号では測定されません。 誰かがunderscore@^x.y.zに依存する依存関係を更新したため、日曜日の午後に電話をかけたくありません。

：thumbsup：うん。 @braddunbarは、私がまだ理解していないことを示しています。semverを無視すると、パッケージが危険で強力なパッケージになります。これは、その重大な変更が_どこでも_長引く可能性があるためです。

壊れたパッケージに依存するサードパーティのコードの中断をユーザーに強制的に追跡させることは、_間違いなく面倒な要件_です。

IMO、実際のライブラリの進捗状況と成熟度は信頼性で測定され、semverはその目標を達成するのに大いに役立ちます。

確かにドキュメントにメッセージがあるはずです。

絶対に。 それが私たちの決定であるならば、私はそれを追加してうれしいです。

私はより良いリリースシステムに反対していません（主はあなたの小さなバグ修正が展開されるのを数ヶ月待つのは苦痛であることを知っています）が、「フォローセムバー」が正しい答えであるかどうかはわかりません。

今のところ、それが1つの正解であるかどうかは重要ではないと思います。 コミュニティが答えを受け入れたのは_です_。

より良いリリースシステムのための正しい答えは「フォローセムバー」だと誰も言っていないと思います。 私たちが言ったことは、それはnpm APIコントラクトであり、そのコントラクトを破るとダメージを与えるということです。

@jdaltonと@dilvieリリースをどのように処理することを提案しますか？ 機能を受け入れるのはどうですか？ 「Usesemver」は実際には何も教えてくれません。

_.matchesのような機能を数か月延期して、現在のコードのバグ修正を待つ必要がありますか、それとも今すぐリリースして、実装の問題を解決する必要がありますか？

semverはここでは完全には当てはまらないと思います。

恥知らずな自己宣伝：next-update https://github.com/bahmutov/next-updateを使用して、プロジェクトを中断せずに依存関係を更新できるかどうかを最初にテストします。 *.*.xを変更したにもかかわらず、さまざまなモジュールで重大な変更を常に見つけていたため、自己宣言されたバージョンを信頼していません。

このプロジェクトはスノーフレークだと思いますか？ Lo-Dashは基本的にUnderscore ++であり、@ jdaltonでは次のsemverは問題ありません。

新機能の受け入れ：

既存のAPI契約に違反しますか？

はい？ -メジャーバージョン番号をバンプします。
番号？ -マイナーバージョン番号をバンプします。

バグ修正/マイナーパッチの受け入れ：

既存のAPI契約を破りますか？

はい？ -メジャーバージョン番号をバンプします。
番号？ -バンプパッチのバージョン番号。

公式リリースのスケジュールをどのように選択するかは、完全にあなた次第です。 他の人のコードを壊さないように、バージョン管理がsemverと互換性があることを確認してください。

@dilvieに同意しました。たとえば、 https： //github.com/jashkenas/underscore/compare/1.3.3...1.4.0は、スパース配列のサポートを終了したため、おそらく大きな問題になるはずです。 lookupIteratorを介して大量の新しい砂糖を追加し、ネイティブイテレータを削除するため、次のバージョンは大きなバンプになるはずです。

関数のドキュメントを変更する必要がある場合は、明らかに大きな変更です

今年のJSconfでこれについて簡単に話し合いました。 ここでは詳しく説明する時間がありませんが、次のようになります。

人間向けの「バージョニング」と、コンピューター向け（または実際にはビルドシステム向け）の「API互換性」との混同をやめましょう。 やめて。

バージョン：「私が好きなものには新しい機能があります。時間があるときに興味があるはずです。」 新しいiPhoneがあります。 新しいOSXがあります。新しいEmberがあります。 アルゴリズム言語スキームに関する新しい改訂レポートがあります。

APIの互換性：「これは修正するために更新されました問題、そしてこれは道を壊すかもしれない/壊すでしょうそのことを行使します。」 iPhoneの電源プラグを交換しました。 OSXは非推奨のリソースフォークです。 Emberはアクション名のスタイルを廃止しました。 スキームでは大文字と小文字が区別されるようになりました。

後者は、前者の_中_、または_一緒に_発生します。 しかし、前者は必ずしも後者に依存しているわけではなく、後者に関連しているわけでもありません。 それらは追跡されるべきであり、（私たちが本当にバージョン管理システムを狂わせるつもりなら、jesus）、別々に指定されるべきです。 （JSコミュニティで人気のある「セマンティックバージョニング」の概念は、_特に_鈍くてひどいものですが、繰り返しになりますが、他の誰かのIssueコメントスレッドで詳しく説明したいことではありません。）

tl; dr：彼らは彼ら自身の道を選ぶことによってあなたの生態系を台無しにしていません。 （_特に_そのパスにひどい欠陥がある場合。）もっと多くのプロジェクトがそうなることを望みます。 あなたがその上で形が崩れているなら、何か他のものを使ってください。

@ elliottcable-人間の向きとコンピューターの向きについて合意...人間の向きがコンピューターの向きとはまったく似ていない限り、混乱はそれほど問題になりません。

たぶん、次の人間向けのリリースをnnnの代わりに「スノーフレーク」のようなものと呼んでください

ただし、最後のビットにはまったく同意しません。 APIコントラクトに従うふりをして、それを破ると、ものが壊れます。 それは他の人々にリアルタイムと実際のお金を要します。 アンダースコアと同じくらい人気のあるプロジェクトでは、実際に多くの被害が発生する可能性があります。

既存のAPI契約に違反しますか？

このスレッドの最初の引数を振り返ってください。 「アンダースコアのすべては基本的に表面積です」、エルゴ、文書化されているかどうかに関係なく、すべてがAPI契約の一部です。 一つの変化は誰にとっても変化です。

Lo-Dashは、「Underscore ++」であるため、主要な機能を実行する際にUnderscoreの背後に安全に追随できるため、機能の変更をほとんど処理しません。 Lo-Dashの改善は、主に内部で、またはいくつかのメソッドを追加することであり、その機能を根本的に再考することではありません。

@ akre54

リリースをどのように処理することを提案しますか？ 機能を受け入れるのはどうですか？ 「Usesemver」は実際には何も教えてくれません。

新しい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の互換性ではなく、「興味深い」バージョンについて話していることを明確にします。これで、勝利のコンボが得られます。

アンダースコア42の+1： 「愚かなシェルティー」。

（ビルドシステムに直面している部分については、自動化された生成的なAPI互換性についていくつかの物議を醸す見解があります。このたわごとをフォールブルメンテナの手から取り除いて、静的分析または動的クロールで攻撃しましょう。）

@ akre54

Lo-Dashは、「Underscore ++」であるため、主要な機能を実行する際にUnderscoreの背後に安全に追随できるため、機能の変更をほとんど処理しません。

それは一体何の意味ですか？ Lo-Dashは_morechanges_を処理し、Underscoreとは別の独自のバージョン管理に従います。 Lo-Dashは大幅に変更され、ドロップインの代替としてのサポートを継続するためにアンダースコア互換ビルドを提供する必要がありました。 さまざまな機能、メソッド、およびさまざまなAPI互換性の問題があります。

Lo-Dashの改善は、主に内部で、またはいくつかのメソッドを追加することであり、その機能を根本的に再考することではありません。

そうではありません。 Lo-Dashはより速いペースで動き、より頻繁にバックコンパットにぶつかります。 これが、〜v2.xが〜v3.xに移行する理由です。 Lo-Dashはアンダースコアのようなものです。 Lo-Dashがsemverをフォローできる場合は、Underscoreもフォローできます。 私はそれを約2年間行ってきました。 あなたの議論は、現実に直面して単純に横ばいになります。

私は前にこの道を進んだことがあるので、みんなもそこに着くのを手伝うことができます。
手始めに、次のアンダースコアリリースは素晴らしい2.0になります。

誰もが「破壊的な変化」をどのように定義すべきだと考えているのか興味があります。 アンダースコアへの_すべての_新機能の変更は、他の誰かにとって重大な変更です。

たとえば、 _.eachに対する最近のすべての変更を見てみましょう。 _.eachの戻り値を変更して元のリストを返すときに、ぶつかったはずですか？ これはバグ修正ですか？ 新機能？ 後方互換性のない変更？ 以前はundefinedを返したので、誰かのコードを壊した可能性は低いです。

内部のeachヘルパーを外部に再割り当てできるようにしたときに、ぶつかったはずですか？ それは誰かのコードを壊した可能性がありますか？ そこではパブリックAPIは変更されていません。

_.eachを変更してスパース配列を回避し、ネイティブforEachの代わりにforループを使用することは明らかに一部の人にとっては壊れていますが、スパース配列が死んでいるので誰が本当に気にしますか？ メジャーバージョンをプッシュする必要があるものですか？ これはバグ修正ですか？

メジャーバージョンのバンプが遅れていると思います（ 219回のコミットで多くのことが発生しました）。 2.0リリースとバージョンポリシーの強化は、ここで大いに役立ちます。

@ akre54

アンダースコアへのすべての新機能の変更は、他の誰かにとって重大な変更です。

必ずしも。

たとえば、_。eachに対する最近のすべての変更を見てみましょう。 元のリストを返すように_.eachの戻り値を変更したときに、ぶつかったはずですか？ これはバグ修正ですか？

これはバグ修正ではなく、拡張機能です。 それは壊れていないのですか？- _.eachの戻り値が信頼されている可能性は低く、開発者がLo-Dashに切り替える際の障害であると報告していないため、おそらく安全な変更です。 疑わしい場合は、破損するか、RCリリースで水域をテストしてください。 変更が_.eachからの早期終了を許可することであった場合、CoffeeScriptを使用しているときに開発者がそれに遭遇したため、これは間違いなく重大な変更だったと思います。

内部の各ヘルパーを外部に再割り当てできるようにしたときに、ぶつかったはずですか？ それは誰かのコードを壊した可能性がありますか？ そこではパブリックAPIは変更されていません。

これは、文書化されていない実装の詳細に該当すると思います。 当時、アンダースコアはまだネイティブメソッドに分岐しているため、この変更では新しいものは何も許可されませんでした。 この変更は、1.6.0以降の変更のより大きなグループに該当するため、2.0に到達する可能性があります。

_.eachを変更してスパース配列を回避し、ネイティブforEachの代わりにforループを使用することは明らかに一部の人にとっては壊れていますが、スパース配列が死んでいるので誰が本当に気にしますか？ メジャーバージョンをプッシュする必要があるものですか？ これはバグ修正ですか？

これはバグ修正と見なすことができますが、間違いなく重大な変更です。 これは、開発者がLo-Dashに切り替えるときに遭遇する問題の1つです。 アンダースコアが以前は使用可能であった場合にネイティブを使用していたため、スパースアレイの使用がマスクされ、開発者は古いブラウザーでテストした場合にのみ問題が発生します。 ただし、この変更により、最新のブラウザーでは、開発者はスパース配列の使用についてより早くアラートを受け取るため、以前に機能していたコードが問題にぶつかる可能性があります。

メジャーバージョンのバンプが遅れていると思います（219回のコミットで多くのことが発生しました）。 2.0リリースとバージョンポリシーの強化は、ここで大いに役立ちます。

：+1：

破壊的な変化（複数の破壊的な変化）

（コンピューティング）他のコンポーネントの障害を引き起こす可能性のあるソフトウェアシステムの一部の変更。 複数のアプリケーションで使用されるコードの共有ライブラリで最も頻繁に発生します
「重大な変更なしに古いエントリを修正することはできないため、インポートライブラリで古いエントリを新しいエントリに再マップします。」

これのいくつかは、いくらかの考えと判断を必要とします。 すべての変更が誰かのコードを破るのは事実かもしれませんが、すべての参加者が、破ることを構成するもののガイドとしてオープン/クローズの原則を使用することに同意する場合、それはすべての人の生活を楽にします。

したがって、APIにプロパティまたはメソッドを追加することは、通常、重大な変更ではありません（APIは拡張のために開かれていますが、後方互換性のない変更に対しては閉じられています）。

関数のシグネチャを変更するには、さらに検討が必要です。

元のリストを返すように_.eachの戻り値を変更したときに、ぶつかったはずですか？

それは、何らかの目的を果たしたAPIの文書化された機能でしたか？ たとえば、一部の関数は、渡された入力が適切な出力にならない場合に未定義を返します。 eachの場合はそうではないようです...したがって、おそらく壊れていません。

一方、スパース配列を回避すると、開発者が依存する戻り値を変更する可能性が高くなるため、これは重大な変更であり、スパース配列を使用した人は誰でも気にかけます。

スパースアレイはES6に耐えられない可能性がありますが、まだ機能していません。

@ akre54
変更が壊れているかどうかの答えが簡単ではない場合があります。 そのような場合、コンテキスト、履歴、およびデータが役立ちます。 幸運なことに、Lo-Dashを新機能のテストの場として使用し、Underscoreからの開発者がどの変更を行うかを確認できました。 アンダースコアは、それを使用して、変更の影響について十分な情報に基づいた決定を下すのに役立ちます。

少なくとも次のsemverは、重大な重大な変更がパッチリリースに組み込まれるのを防ぎ、開発者が変更の影響について考えるように促します。 それは誰にとっても勝利です。

@jdalton 、クラスアクト。 :)