Backbone: SemVerをフォローする

感謝しますが、厳密に「セマンティック」バージョン管理に従うと、Backboneではうまく機能しません。 プロジェクトがほぼすべての表面積であり、内部がほとんどないことを考えると、バックボーンへのほとんどすべての変更（パッチ、プルリクエスト）は下位互換性を少しだけ壊します...以前に定義されていない動作に依存している人々だけであっても。

「セマンティック」バージョン管理に厳密に従った場合、おそらく今ではBackbone.js 43.0.0になります。これは、プロジェクトの実際の進行状況を評価するのに役立ちません。

だから、私が冗談を言うのが好きなように—「セマンティック」バージョンではなく、_ロマンチックバージョン_。

バージョン番号MAJOR.MINOR.PATCHを指定して、以下をインクリメントします。

メジャーな新しいリリースを作成するとき、またはAPIを大幅に更新および/または安定化するときのメジャーバージョン。
マイナーな新機能を追加するときのマイナーバージョン。
小さな変更を加えたときのパッチバージョン。ほとんどの人が気付かない可能性があります。

これにより、人々は新しいリリースについて聞いた直後に、その範囲の大まかな感覚を得ることができます。 下位互換性について—理想的には、主要なリリースであっても、すべてのリリースに下位互換性があります。 また、APIが変更されているために変更できない場合は、アップグレードがそれほど難しくない方法で実行する必要があります。

ただし、APIへの変更を回避し、「メジャー」リリースの準備が整うのを待つことは、進行を妨げる大きな障害になります。 そして、メジャーバージョン番号を頻繁にインクリメントするという選択肢は、信じられないほど役に立ちません。

正直なところ、ほとんどのデスクトップアプリケーションと同じように、 BIG.SMALLバージョン番号を使用した単純なスキームを好みます...しかし、パッケージマネージャーやその他のツールが壊れることを心配しています。

バックボーン43.0.0にいることの問題は何ですか？

• Chrome32.0.1700から送信

spadgos @の質問には+1。 バージョン番号は任意です。 何らかの理由で、OSと同じ範囲内に維持しようとするアジャイルWebアプリがあります。 多くのアプリは10を超えることに夢中になっています...しかし、モデル化するプロジェクトのほとんど（Windows、Linuxなど）には、リリース前に1年/複数年の開発サイクルがあるため、1.x-> 2.x大したことです。 アジャイルプロジェクトは非常に迅速に移動し、迅速にインクリメントすることも理にかなっています。

私もこの背後にある理由に同意しません。

Marionetteは現在v1.2.3を使用しており、厳密なセマンティックバージョン管理に従うのが最善です。 これまでのところ、「全表面積」でも問題はありません。 新しい機能を追加しました。 バグを修正しました。 ただし、v1.0はv1.2.3と互換性があります。 v2リリースのチケットがAPIである場合、または動作を壊す変更が予想される場合は、チケットを延期しました。

重大な変更を伴うメジャーリリースは、プルリクエストが受け入れられたときに毎週発生する必要はありません。 これらは、メジャーバージョンのバンプを伴う大規模なリリースに十分な価値を含むメジャーリリースにプールすることができます（そしてプールする必要があります）。

現状では、v1.1リリースで互換性が失われると、MarionetteJSチームのようなプラグインおよびアドオン開発者に多くの苦痛が生じます。 v1.0とv1.1の両方で実行可能な状態を維持できるように、コード内のパッチで動作を埋め戻す必要がありました...これは楽しい状況ではありません。 バックボーンのようなコアライブラリの波及効果は非常に大きく、影響を受けるのはバックボーンだけではありません。

私は、これが「できない」というよりも「したくない」の場合のように見えることに同意します。 https://github.com/jashkenas/backbone/pull/2461などの重大な変更には、緊急性はなく、43.0.1の問題が必要ない場合は、メジャーバージョンの更新を待つことができます。

私にとって、背骨が（とりわけ）背骨を尊重しないことの最大の問題は、背骨を教え、伝道することです。 学生のグループや潜在的な顧客に、スタック内のすべてが特定の方法で機能することを伝えるのは素晴らしいことではありません...バックボーンを除きます。

バックボーンを「伝道」する際には、常に2つの大きな注意点があります。AMDはそのままではなく、SemVerを尊重しないため、バージョン番号を真剣に受け止めないでください。 それらの1つが修正されました。 もう一方を修正しましょう。

正直なところ、ほとんどのデスクトップアプリケーションと同じように、BIG.SMALLバージョン番号を使用した単純なスキームの方がいいと思いますが、パッケージマネージャーやその他のツールが壊れることを心配しています。

@jashkenas常に3桁目を.0のままにしておくことができます:)

これはおそらく、現在行っていることよりも少し近いSemVerに意味的にマッピングされます。 たぶんそれは、SemVerに従わないことがどういうわけか技術的に間違っているかについての受動的攻撃的な暗号政治的狙撃のいくつかを弱体化させるでしょう。

ボブの主張は、私たちが従うシステムに関係なく、私たちが従うシステムを明確に表現することがより重要であるという点で正しいと思います。

ps @keithamusの問題が受動的攻撃的であることを意味するつもりはありませんでした。そのようになってしまった場合は、申し訳ありません。 Backboneが変更をユーザーに伝達する方法について議論することは間違いなく合法です。

：+1：semverの場合。 私は主に、特定のソフトウェアのバージョンを、その進捗状況の指標としてではなく、互換性の指標として関心を持っています。

一般に、1.0以降（物事がほぼ安定して機能していると予想される場合）、バージョン番号は進捗状況の指標としてほとんど意味がありません。 バージョン10のソフトウェアXは、バージョン2のソフトウェアYよりも成熟度が低く、機能が少ない可能性があります。ソフトウェアの進捗状況を知りたい場合は、その変更ログまたはロードマップを確認する必要があります。

バックボーン（またはその他）が2.4.3であることを知っていても、その機能に関しては何の意味もありません。 ただし、2.0.4から何も壊すことなくアップグレードできることを意味します。

「セマンティック」バージョン管理に厳密に従った場合、おそらく今ではBackbone.js 43.0.0になります。これは、プロジェクトの実際の進行状況を評価するのに役立ちません。

非常にマイナーな/おそらく存在しない問題。 semverをフォローしていませんか？ 大問題。

：+1：、semverはそのような大きなプロジェクトになくてはならないものです。

私は@knowtheoryと一緒です。 43.0.0は少し奇妙に見えますが、 1.43.0は問題なく、 npm install後で誰も突然の破損を被ることはないと思います。

バージョン番号が高いことを誰が気にしますか？
それは標準です、あなたがそれを使うことができるならば、あなたはそれを使うべきです。
この議論がなぜそんなに長く続くのか私も理解していません。

：+1：＃2996と＃2997のいくつかの問題、および他のいくつかのバックボーンリリースで発生した問題を防ぐことができたでしょう。

@braddunbar （および「反対」のその他の理由）は、実際の意味よりもバージョン番号の美学を重視しているように聞こえます。

感謝しますが、厳密に「セマンティック」バージョン管理に従うと、Backboneではうまく機能しません。

Backboneが（依存関係の管理を使用して）ユーザーにとってうまく機能することが重要だと思います。 次のどのsemverが保証するか…

より頻繁なリリースは、ショートッパーのバグをより早くキャッ​​チするのに役立ちます。 必要なバグ修正を取得するためだけに、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ドキュメントから：

「バージョンは、依存関係としてnpmにバンドルされているnode-semverで解析可能である必要があります（npm install semverを使用して自分で使用してください）。」

semverとして解釈されたときにバージョン番号が_lie_である場合、それは正しい構文解析ではありません。 したがって、あなたはpackage.json契約を破り、人々がnpmエコシステムでパッケージバージョンを使用する方法との互換性を破っています。

それは個人的な好みの問題だけではありません。 それはパッケージの相互運用性の問題です。

semverを使用しない場合、パッケージを強制的に正常に再生することはできますか？ _確かに_ですが、readmeの上部で大声で大胆に声を出さないと、それが必要であることを知っているユーザーはほとんどいません。重大な変更を導入すると、コードが非常に簡単に破損する可能性があります。

パッケージをパッケージリポジトリに公開すると、バージョン管理は相互運用性コントラクトの一部になります。 あなたはあなたのユーザーの危険でその契約を無視します。

npm install --save [email protected]は面倒な要件ではありません。

本格的なアプリケーションに組み込まれる何千ものパッケージのどれを知っているかは、面倒な要件でこれを行う必要があります。 いくつかのモジュールがルールに従わないため、ユーザーにすべてのパッケージのバージョンを厳しくロックダウンすることを強制します。これは、バグ修正やセキュリティパッチなどに対応する問題を複雑にするため、面倒な要件です...

semverに従うのには非常に正当な理由があります。 「私のパッケージ番号が本当に大きくなるかもしれない」というのは、semverを使用しないというひどい理由です。 アプリケーションの進行状況を追跡することは、パッケージバージョンの遠い2番目の理由です。 このバージョンの最も重要な機能は、「このバージョンは私のアプリケーションで機能するか」を知ることです。

ところで、パッケージ番号が非常に大きくなる場合は、コードの臭いかもしれません。 _重大な変更_を行う場合にのみ、メジャーバージョンをバンプする必要があります。 定義による重大な変更とは、_開放/閉鎖原則を破る_変更です。 拡張のために開き、変更を壊すために閉じます。 すべての優れたAPIは、オープン/クローズの原則に可能な限り厳密に従うため、ユーザーはAPIに対応でき、変更によって既存のコードが破損することはありません。

ここで学んだ教訓は、「package.jsonを介してBackboneをプルするときに~または^使用しないでください」だと思います。

@ akre54semverについてのあなたの見方に興味があります

一般的に私はここでの議論に同意しますが、メジャーバージョンをぶつけることが_すべての_重大な変更に対する最善の行動であるかどうか疑問に思う必要があります（そして、アンダースコアはほとんど表面積であり、それは_たくさん_です）。 アンダースコアは多くのサードパーティライブラリで使用されており、それらすべてに巨大なバージョンに対応するように要求することは、面倒で危険です。 （本日リリースされたパッケージは、バージョン2までのアンダースコアに依存する必要がありますか？1.7？1.6.x？メインプロジェクトとは別のアンダースコアが必要になる可能性がありますが、依存関係を固定する必要がありますか？）

ここで学んだ教訓は、「package.jsonを介してBackboneをプルするときに〜または^を使用しないでください」だと思います。

うん。

ここで学んだ教訓は、「package.jsonを介してBackboneをプルするときに〜または^を使用しないでください」だと思います。

これが持ち帰りのレッスンであってはならない理由を上で概説しました。

ここで学んだ教訓は、「package.jsonを介してBackboneをプルするときに〜または^を使用しないでください」だと思います。

結果として、コードの破損から保護するためにこれを行います。

レッスンは、「次のsemverはすべての人にとって良いことですが、そうしないことはそうではありません」のようなものになります。

「ロマンチックな」バージョン管理の価値を理解できます。 残念ながら、それらはあまりうまく共存していません。

semverに厳密に従わないプロジェクトや、それを試みても不十分なプロジェクトが常に存在するため、システムは常に少しリークすることに注意してください。

少なくともバックボーンは、一般的に物事を壊さないことについて非常に優れています。

@dgbeckはバージョンごとに常に壊れています私の以前のコメントを参照してください

ですから、あまり話題になっていない次のsemverの価値は、マイナーな機能やバグ修正をプッシュして、上流に依存している人々がこれらの変更を無料で入手できるという事実だと思います。

私にとってこれは大きな付加価値ですが、明らかにこれはメンテナにとって複雑さを犠牲にしてもたらされます。