問題タブ [semantic-versioning]

App Store にアプリのバージョン 2.0.3 があります。今、私は2.0.4バージョンを送りたいと思っています。しかし、デバッグ中、Harpy は常に 2.0.3 への更新を要求します。どこが間違っていますか？次のバージョンは何ですか？

を使用しております：

• ビルドする Gradle (ビルドスクリプト)
• CI 用の竹
• ビンレポのArtifactory

Bamboo では、Artifactory Gradle プラグインを使用して、ビルドされた JAR を Artifactory に公開します。

Artifactory、Gradle、または Artifactory-Gradle プラグインには、バージョン番号に従ってバージョン番号を自動的にインクリメントする機能がありますsemverか?

このメカニズムでは、パッチ/ビルド番号を自動的にインクリメントし、メジャー/マイナー番号を CI スクリプト変数として取り込む必要があります (新しいメジャー/マイナー リリース バージョンを準備するときに手動で変更します)。さらに、このメカニズムでは、メジャー/マイナー リリースが発生するたびに、パッチ/ビルド番号をゼロにリセットする機能が必要になります。

これはオプションですか？もしそうなら、どのように？

REST API (ヘッダー、URL など) の多数のバージョン管理スキーマを評価しました。これまでのところ、最も信頼できるアプローチは url オプションのようです。これはプロキシで動作し、バージョン管理の日付などのあいまいなスキーマに依存しません。

今、私が周りを見回すと、URL ベースのアプローチを使用する人は皆v1、v2、 などのバージョンを使用しているようです。マイナー バージョンや、セマンティック バージョニングなどのスキーマを使用する人はいません。

これにより、いくつかの疑問が生じます。

• REST API のバージョン番号を増やすのはいつですか (確かに、5 年に 1 回以上の更新があります)。
• バグを修正しただけの場合は、おそらくバージョン番号を上げませんが、両方のバージョンをどのように区別していますか?
• 非常に細かいアプローチを使用すると、並行してホストする必要がある多数のバージョンが発生します。それをどのように処理しますか？

言い換えれば、たとえば GitHub のような企業は、たとえばv37 年前から営業を続けているのに、今日 (2015 年) しか持たないのはなぜでしょうか? それは、彼らが実際に API を 2 回だけ変更したということですか? 信じられません。

ヒントはありますか？

セマンティック バージョニングの重要性を友人に説明しようとしたとき、次のようなジレンマに直面しました。

次の関数を公開するlibfooversionの library があるとします。1.2.3

ここで、この関数とそのドキュメントが次のように変更されたとします。

私の第一印象は1.2.4、パブリック インターフェイスが変更されていないため、次のバージョンは になるだろうということでした。たとえば、次のように関数を呼び出す人は、変更にまったく気付かないでしょう。

しかし、もう少し考えてみると、Python では名前でパラメーターを指定できるため、これはAPI の中断である可能性が非常に高いです。誰かが私の関数を次のように呼び出すとしたら:

これは version1.2.4では機能しなくなり、セマンティック バージョニング コントラクトが破られます。

一方で、このような変更は非常に小さいため、バージョンを に上げるのは気が引け2.0.0ます。

要約すると、これは API の中断を構成しますか? この場合、次のバージョン番号は何にする必要がありますか?

私の会社は10年間システムを開発しています。このシステムには、ほぼ独立した 15 のサブシステムがあり (同じライブラリ、パッケージ、または DB を使用する場合があります)、これらのサブシステムは別々のチームでローカルに構築されています。また、サブシステムの構成を読み取り、メニューとサブメニューを含むページを構築するためのメインのシンプルなシステムが開発されています。構成から（ショートカット付き）。当社製品は、このメインシステムのexeです。

残念ながら、当社では標準のバージョン番号を使用していません。さて、社内に標準を強制することにしました。セマンティック バージョニングは満足のいく標準であることがわかりましたが、私たちの場合、いくつか質問があり ます。多くの場合、サブシステムに大幅な変更を加えた後でも、メイン システムのコードは影響を受けません。メインシステムの変更はそのシステムのバージョン番号を形作るべきだと思いますが、この場合は意味がありません. 複数のサブシステムで構成される大規模なアプリケーションをバージョン管理するためのソリューションはありますか?

でのバージョン管理について調べていたところ、どうやらパッケージのバージョンを上げるnpmための便利なコマンドが提供されているようです。

プレリリース

パッケージがバージョンで始まるとしましょう0.0.0

npm version prerelease=>0.0.1-0

npm version prerelease=>0.0.1-1

基本的には、ダッシュの後に数字をぶつけるだけです

プレパッチ

0.0.0代わりに pre[major|minor|patch] を使用することから始めます...

npm version prepatch=>0.0.1-0

npm version preminor=>0.1.0-0

npm version premajor=>1.0.0-0

パッチ

0.0.0パッチの使用から開始...

npm version patch=>0.0.1

npm version patch=>0.0.2

メジャー マイナー バージョンとパッチ バージョンをバンプするためのルールは理解していますが、以前のバージョン管理の標準的な規則は何1.0.0ですか?

私はScala でパーサー コンビネーターを使用して SemVer ( http://semver.org ) パーサーを作成しようとしています。

これは私の現在のコードです:

プレリリース セクションの識別子を解析する方法を知りたいのですが、数値識別子の先行ゼロが許可されておらず、現在のパーサーを使用して先行ゼロ (たとえば "01.2.3") を解析しようとすると、単純にリストになるためです。要素 0 を含みます。

より一般的には、文字列が SemVer 仕様に準拠していないことをどのように検出し、その結果、障害状態を強制する必要がありますか?