セマンティック バージョニングについて検討する

  • 4 分

バージョン管理の主な方法の 1 つは、 セマンティック バージョニング (SemVer) の使用です。

セマンティック バージョン管理 は標準ではありませんが、特定のバージョンの 意図 と セマンティクス を一貫して表現する方法を提供します。

以前のバージョンとの 下位互換性 のためのバージョンについて説明します。

セマンティック バージョン管理の形式

セマンティック バージョン管理 では、 3 部構成のバージョン番号 とオプションの ラベルが使用されます。

Major.Minor.Patch 形式

バージョンの形式は Major.Minor.Patch で、前のセクションで説明した 3 種類の変更に対応します。

バージョン構造:

  • 少佐： 最初の数値は、破壊的変更を示します。
  • マイナー： 2 番目の数値は、新機能 (下位互換性) を示します。
  • パッチ： 3 番目の数値は、バグ修正 (下位互換性) を示します。

セマンティック バージョン管理スキームを使用したバージョンの例:

  • 1.0.0 - 初期安定リリース
  • 3.7.129 - 多数のマイナー更新プログラムとパッチ更新プログラムを含むバージョン 3
  • 2.0.0 - 重大な変更を伴うメジャー バージョン 2

これらのバージョンにはラベルはありません。

バージョン増分規則

各数値をインクリメントするタイミング:

メジャーのインクリメント (X.0.0)

  • 破壊的変更: 互換性のない API の変更を行います。
  • 機能の削除: 非推奨の機能を削除します。
  • アーキテクチャの変更: 基本的な再設計。

Example:

  • 1.5.3破壊的変更が導入されたときの→ 2.0.0

マイナーのインクリメント (x.Y.0)

  • 新機能: 下位互換性のある方法で機能を追加します。
  • 非推奨の機能: 機能を非推奨としてマークします (ただし、引き続き機能します)。
  • 強化： 既存の機能の大幅な改善。

Example:

  • 1.5.3 新機能を追加するときに 1.6.0 に切り替えます

インクリメント パッチ (x.y.Z)

  • バグ修正: 下位互換性のあるバグ修正を行います。
  • セキュリティ パッチ: セキュリティの脆弱性を修正します。
  • パフォーマンスの向上: パフォーマンスの小さな最適化。

Example:

  • 軽微なバグの修正のための 1.5.3 から 1.5.4

プレリリース バージョン

プレリリース バージョンの場合は、通常のバージョン番号の後にラベルを使用するのが慣例です。

ラベルの形式

ラベルは、バージョン番号の残りの部分からハイフンで区切られたテキストサフィックスです。

ラベル自体には、 プレリリースの性質を説明する任意のテキストを指定できます。

ラベル構造:

Major.Minor.Patch-label

一般的なプレリリース ラベル

これらの例としては、 rc1、 beta27、 alphaがあり、次のようなバージョン番号が形成されます。

  • 1.0.0-alpha - 初期の開発バージョン、不安定。
  • 1.0.0-beta - 機能は完全ですが、バグが発生する可能性があります。
  • 1.0.0-beta.2 - 2 番目のベータ 版。
  • 1.0.0-rc1 - リリース候補。リリースの準備ができている可能性があります。
  • 1.0.0-preview - 早期フィードバックのプレビュー バージョン。

バージョンの進行状況の例:

1.0.0-alpha.1
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-beta.2
1.0.0-rc1
1.0.0-rc2
1.0.0

プレリリース のラベル規則

一般的なラベル プレフィックス:

  • アルファ： 非常に初期のバージョンでは、バグや破壊的変更が予想されます。
  • Beta： 機能が完成し、テスト中です。
  • rc (リリース候補): 最終バージョンの可能性がある、最後のテスト フェーズ。
  • プレビュー： フィードバックの早期プレビュー。
  • dev: 開発スナップショット。

数値サフィックス:

多くの場合、ラベルにはシーケンシャルプレリリースの番号が含まれます。

  • 1.0.0-beta.1 → 1.0.0-beta.2 → 1.0.0-beta.3

プレリリース バージョンの使用

プレリリース は、パッケージのラベルのないバージョンのリリースに備える一般的な方法です。

プレリリースの利点

早期のフィードバック:

早期導入者 は、プレリリース バージョンに依存して、新しいパッケージを使用してビルドできます。

  • テスト統合: パッケージが既存のシステムで動作することを検証します。
  • 問題を報告する: 公式リリース前にバグを見つけます。
  • フィードバックを提供します。 改善点や変更を提案します。

段階的なロールアウト:

  • 段階的なリリース: 最初に少数の対象ユーザーにリリースします。
  • リスク軽減策: ワイド リリースの前に問題をキャッチします。
  • 信頼度の構築: 安定性の信頼性を高めます。

プレリリースに関する注意事項

一般 に、リリースされたソフトウェアにプレリリース バージョンのパッケージとそのコンポーネントを使用することはお勧めしません。

運用環境でプレリリースを使用するリスク:

  • 不安定： プレリリースでは、未検出のバグが発生する可能性があります。
  • 破壊的変更: 将来のプレリリースでは、破壊的変更が発生する可能性があります。
  • 保証なし: 下位互換性の保証はありません。
  • サポートの制限事項: プレリリース バージョンに対する制限付きまたはサポートなし。

プレリリース バージョンのテスト

コードベースに別のブランチを作成し、プレリリース バージョンのパッケージを使用することで、新しいコンポーネントの影響を期待することをお勧めします。

プレリリースをテストするためのベスト プラクティス:

  • 別のブランチ: テスト用の機能ブランチを作成します。
  • 分離環境: 非運用環境でテストします。
  • 監視動作: 予期しない動作やパフォーマンスの問題に注意してください。
  • ドキュメントの問題: 見つかった問題を追跡します。

プレリリースから最終バージョンへの互換性のない変更が発生する可能性があります。

メタデータとビルド情報

SemVer 2.0 では、プラス記号が付加された ビルド メタデータ もサポートされています。

1.0.0-beta.1+20231015.abc123

ビルド メタデータ:

  • バージョンの優先順位では考慮されません。 ビルド メタデータでのみ異なる 2 つのバージョンが等しいと見なされます。
  • 情報の目的: ビルド番号の追跡、ハッシュのコミットに役立ちます。
  • 例:1.0.0+build.123 又は 1.0.0-beta+exp.sha.5114f85

バージョンの優先順位

SemVer では、バージョンの優先順位に関する明確な規則が定義されています。

比較規則

  1. メジャー、マイナー、パッチの比較: その順番で数値的に比較する。
  2. プレリリース バージョン: 常に、関連付けられている通常のバージョンよりも優先順位が低くなります。
  3. ラベルの比較: 英数字セグメントは字句的に比較され、数値セグメントは数値で比較されます。

順序の例 (最低から最高):

1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta
1.0.0-beta.2
1.0.0-beta.11
1.0.0-rc.1
1.0.0
1.0.1
1.1.0
2.0.0

セマンティック バージョン管理の利点

明確なコミュニケーション:

  • 意： バージョン番号は、変更の性質を明確に伝えます。
  • 互換性： 更新が安全かどうかを簡単に判断できます。
  • 予測： パッケージ間で一貫したバージョン管理。

依存関係の自動管理:

  • バージョンの制約: パッケージ マネージャーは、バージョンを自動的に解決できます。
  • 安全な更新プログラム: ツールは、互換性のあるバージョンに安全に更新できます。
  • 競合の解決: 依存関係の競合を簡単に解決できます。

エコシステムの導入:

  • 業界標準: 多くのエコシステムで広く採用されています。
  • ツールのサポート: パッケージ マネージャーは SemVer を理解します。
  • コミュニティの期待: 開発者は SemVer コンプライアンスを期待しています。

Azure Artifacts でのセマンティック バージョン管理

Azure Artifacts では、 すべてのパッケージの種類で セマンティック バージョン管理が サポートされています。

  • NuGet: ネイティブ SemVer 2.0 のサポート。
  • npm: SemVer が標準です。
  • Maven: SemVer の原則と互換性があります。
  • PEP 440 は SemVer の概念と互換性があります。
  • ユニバーサル パッケージ: SemVer 2.0 を使用します。

フィード ビューと SemVer:

  • @Prerelease ビュー: ラベル付きのバージョンが自動的に含まれます。
  • @Release ビュー: ラベルのないバージョンのみが含まれます。
  • @Local ビュー: ラベルに関係なく、すべてのバージョンを表示します。

セマンティック バージョン管理の実装

手動バージョン管理:

  • パッケージ ファイルを更新する:package.json、.nuspecなどでバージョンを手動で更新します。
  • タグを使用したコミット: バージョン番号を使用してコミットにタグを付け。

自動バージョン管理:

# Using npm version command
npm version patch  # Increment patch: 1.0.0 -> 1.0.1
npm version minor  # Increment minor: 1.0.1 -> 1.1.0
npm version major  # Increment major: 1.1.0 -> 2.0.0

# With prerelease
npm version prerelease --preid=beta  # 1.0.0 -> 1.0.1-beta.0

CI/CD パイプラインの場合:

# Azure Pipelines example
- task: GitVersion@5
  inputs:
    runtime: "core"
    configFilePath: "GitVersion.yml"

- script: |
    echo "Semantic Version: $(GitVersion.SemVer)"
    echo "NuGet Version: $(GitVersion.NuGetVersion)"
  displayName: "Display version"

「セマンティック バージョニング 2.0.0」も参照してください。