問題タブ [semantic-versioning]

同じくsemverに続く別ライブラリのラッパーにsemverを採用しようと考えています。当初は、ラッパーのバージョンを元のライブラリと同じに保つだけでよいと考えていました。

ただし、元のライブラリとは関係のないバグやパッチがラッパー自体に存在する可能性があるため、これはそれほど単純ではありません。言うまでもなく、ラッパーの開発自体は段階的であり、すべての機能が一晩で準備完了になるわけではありません。

ラッパーが参照する元のライブラリのバージョンと、ラッパー自体のパッチと開発履歴の両方を考慮して、このラッパーのバージョン管理を行うための推奨される方法は何ですか?

私はセマンティック バージョニング スキームがとても気に入っていますが、重要なのは API のみです。エンドユーザー ソフトウェアなどの非 API の場合、ルールの多くはあまり意味がありません。たとえば、下位互換性という概念そのものは、実際には何の意味もありません。ユーザーが新機能を体験するか体験しないか、バグが少ないか体験しないか、など。ただし、セマンティック バージョニングの精神に従う xyz バージョニングの明確なスキームがあれば、ユーザーは何を期待できるかを理解できるようになります。スキームに精通している場合は、新しいバージョン番号から。

次のようなものをスケッチしてみました。

• ユーザー エクスペリエンスを変更しないコードの内部変更 (バグ修正、リファクタリングなど) を行う場合は z をバンプします。新しい「内部」機能が含まれる場合があります。
• バグ修正を超えてユーザー エクスペリエンスを変更する機能を現在の機能に追加する場合は、バンプ y を使用します。
• バンプ x...???...ユーザー エクスペリエンスに根本的に異なる変化はありますか? 根本的に違うのは何ですか？
• 最初のアルファ開発は 0.0.z として発生します
• 最初のベータ テスト リリースは 0.1.0 に設定され、0.yz のままです
• 最初のユーザー リリースは 1.0.0 に設定されます

別のアイデアは、一部のユーザーがそれらに依存している可能性があるため、機能が削除されたときに x バンプを作成することですが、場合によってはそれは不当に見えるかもしれません。(あなたがすべてのユーザーを知っていて、彼ら全員が非常にマイナーな機能の削除を望んでいるとします。1.0 から 2.0 に移行することは、やや直感に反するでしょう。)

これはセマンティック バージョニングよりも主観的です。後方互換性のある機能や API の破壊的な機能を客観的に特定する方がはるかに簡単だからです。詳細なガイダンスを得るために調査できる「標準化された」バージョン管理スキームはありますか?

bower.json を記述するときに、依存関係でバージョン番号を指定できます。書いてる人をたまに見かけます

~ とは正確にはどういう意味ですか? なぜ >=0.3.13 と書かないのですか?

これはある種のベストプラクティスですか？

Bower では、次の構文を使用してパッケージのバージョン要件を指定できます。

しかし、に使用する構文を見つけることができませんでした<version>。バージョンを次のように指定できることを知っています。

• 特定のバージョンより大きい">1.0.0"
• バージョン以上:">=1.0.0"
• またはある範囲で: "1.0.0 - 2.0.0".

また、チルダを含む一般的なバージョン構文があることも知っています: "~1.0.0". しかし、それが何を意味するのか、それが と同じかどうかはわかりません"=1.0.0"。

また、複数の連続しないバージョンを指定できるかどうかも知りたいです。たとえば、正確に1.0.3加えて より大きいバージョン1.5.0などです...

Java ライブラリにセマンティック バージョニング ( http://semver.org/ ) を導入しています。

新しい列挙値の追加をどのように処理する必要がありますか? 私たちの状況は次のとおりです。

• annotations.jarタイプのプロパティを持つ注釈を含むMyEnum
• util.jarannotated from を使用して注釈が付けられたオブジェクトがありますannotations.jar
• wsprovider.jarjaxb のようなテクノロジーを使用して、アノテーション付きオブジェクトをutil.jarWeb API にシリアライズします
• wsconsumer.jarによって提供される Web API を使用wsprovider.jarし、 の値に基づいて切り替えを行い、MyEnum動作を変更します。

に新しい値を追加する場合MyEnum、さまざまな jar のどの部分 (メジャー/マイナー/パッチ) をバンプする必要がありますか?

util.jarAPI が既存のコードを壊す可能性のある方法で変更されたため、メジャー バージョンを更新する必要があるように思えます。

同じ論理により、これは波及して と の大きな隆起にwsprovider.jarなりwsconsumer.jarます。

annotations.jarメジャー バージョンの更新は必要ですか?

列挙型は値の閉じたセットであるため、はいと言います。そのため、コード ( などwsconsumer.jar) は、列挙型のすべての値をカバーすることで、可能なすべての動作をカバーすることを前提としています。列挙型に新しい値を追加すると、それが壊れます。

しかし、本能的には、列挙型に単一の値を追加するのは少し多すぎるように思われ、かなりの波及効果があります。

これは、semverに慣れる必要があるだけだと思いますか?

「angular-backstrech-adrr」のバージョンを bower に登録します。

bower register angular-backstrech-adrr git@github.com:AladdinMhaimeed/angular-backstrech-adrr.git

これはbower.jsonです：

}

Bower は正常に登録されたと言っていますが、使用すると:

利用可能なバージョンはありませんと表示されます。

バージョンを変更して再度登録しようとすると、EDUPLICATEが表示されます。

bower.json に何か問題がありますか? 構文に何か問題がありますか?