問題タブ [semantic-versioning]

私は自分のrpmを構築しています。今のところ0.1、ビルドバージョン0.2などがあります。セマンティックバージョニングを使用したいと思います。それを変更すると、依存関係がどのように機能するのだろうか？

古いバージョン0.5と新しいバージョンがあるとし0.6.0ます。数字はどのように解釈されますか？

古いバージョンは として解釈さ0.5.0れ0.0.5ますか? バージョンに応じて別のrpmを使用する0.4.0と、問題が発生する可能性があります...では、と0.4.0比較してどうなり0.5ますか?

したがって、「myLibrary」は「anotherLibrary」を参照します。どちらのライブラリもhttp://semver.org/に従います

コンシューマーに anotherLibrary の新しいメジャー バージョンへの更新を強制する myLibrary の新しいバージョンをリリースした場合、myLibrary のメジャー バージョンもインクリメントする必要がありますか?

オープンソースにして将来のプロジェクトで使用したいパッケージの開発を始めています。ただし、これを開始するための適切な手順がわかりません。

github にリポジトリを作成したところです。composer.json

ただし、バージョン管理に頭を悩ませるのに苦労しています。私は git タグを作成していません。branch-aliasそれが良い習慣だと聞いたからといって、私はそれをつけました. 私は1.0.x-dev今何がそこにあるべきか分かりません。

この時点で何をすべきですか？私は 1.0 バージョンに慣れているわけではありません。「v0.1.0」のような軽量または注釈付きの git タグをすぐに作成するか、完全に機能するようになるまで待つ必要がありますか?

あとで頭が痛くならないようにするにはどうしたらいいですか？

コンポーザーはバージョニングにgitタグを使用していると思います(?)

maven multi-module6 つ以上の子モジュールを含むプロジェクトがあります。3 人のチームがそれぞれ 2 つのタスクとして並行して作業している場合sub-modules、バージョン番号を増やす方法。

一方、私はMajor.minor.patch-metaリリース サイクルでのバージョン番号付けの形式に従っています。

でのバージョン番号の増減の正確な使用法parallel programming。これで通知される重要なことはsub-modules、そのプロジェクトの一部が他のプロジェクトに完全に依存するsub-moduleことですが、その場合、開発が並行して行われている間に正確にバージョン番号を付ける方法注文 ？

以下については明確ではありませんが、これはバージョン番号付けの正しい方法ですか

1. meta releaseアルファ、ベータ、ガンマなどのバグ修正の場合に行う必要がある場合は、

2. 0.1.1-alpha、0.1.2-alphaなどを使用しているのに、apatch releaseの完了の場合にaを実行する必要がありますか?feature[sub-sub-module-x]sub-modulesecond level+ sub-modules

3. minor releaseたとえば、 0.2.0-alpha 、 0.2.0-RC などの完了の場合に行う必要がありsub-moduleます。
4. したがって、すべての RC の 0.2.0-RC + 0.3.0-RC + 0.4.0-RC などを統合した後、major releaseas 1.0.0-RTM などを実行する必要があります。

したがって、上記の流れを理解するのは少し混乱します..

build numberingclear を維持するために、プロジェクトでを自動化する方法はありますかbuild release numbers。解決策を提供してください。

ありがとう

このブログ投稿と関連するGistを見つけました。作成者は対応する NuGet パッケージを作成していないようです。

既に存在する NuGet パッケージを知っている人はいますか?

参考までに、セマンティック バージョニングの仕様を次に示します。

semver パッケージを使用して、ライブラリのバージョンが必要かどうか、互換性のあるバージョンがあるかどうかを確認する簡単な方法がわかりませんでした。一般的な操作のように見えるので、明らかな何かが欠けているのではないかと思いました。

Semver.orgによると、同じまたは新しいが、新しいメジャーバージョンではないバージョンは互換性があると想定されています。したがって、私が必要1.2.3とし、私が持っている>=1.2.3 <2.0.0場合、それはすべて良いことです. その比較は手作業で作成できますが、あまりにも一般的なので、もっと簡単な方法を見逃していないか気になります。

言い換えれば、私は明らかにこれをしなければならないようです

どちらが機能しますか

はい、それは小さなコードです。X は Y と互換性があるかどうかを確認するためだけに、文字列を操作して範囲比較を手動で作成する必要がないほど一般的な操作のように思えました。

もっと簡単な方法はありますか？

簡単に言うと、私は VisualBasic 6 プロジェクトのメンテナーであり、ActiveX COM DLL を生成します。このプロジェクトは、組織内で内部的に使用される約 50 の他のソフトウェア パッケージによって内部的に使用されます。

過去数年間、リリースされた各 DLL のセマンティック バージョニング "MAJOR.MINOR.PATCH" に従い、リリースごとに一意の GUID を割り当ててきました。つまり、1.1.1 と 1.1.2 には別々の GUID があります。

問題なく動作しましたが、これにより、新しい GUID を参照して再コンパイルできるようにするためだけに、ソフトウェア パッケージのそれぞれが新しいリリースを必要とするようになります。これは、リリースのための内部プロセスにより、数十時間の工数を浪費します。

私の質問は、1.1.1、1.1.2、さらには 1.1.99 が同じ GUID を持つように、マイナー リリースごとに GUID を維持するのは「悪い習慣」でしょうか? 代わりに、メジャー リリースごとに GUID を作成する方がよいでしょうか?

これにより、新しいメジャーまたはマイナー リリースが作成されたときにのみ参照が変更され、それに依存するソフトウェア パッケージに必要な変更の数が減ります。

最後に、応答に役立つ場合、現在 DLL は MyActiveXDLL_vMAJOR.MINOR.PATCH.dll という名前になっています。

MINOR ごとの GUID を使用して、MyActiveXDLL_vMAJOR.MINOR.dll に切り替えます。