• バージョニング
• アップグレードの推奨事項
• メジャーバージョンへのアップグレード
• パッチリリース
  • 旧バージョンへのバックポート
  • セキュリティリリース
• 詳細情報

GitLabのリリース・メンテナンスポリシー

GitLabでは、メジャーリリース、マイナーリリース、パッチリリース、セキュリティリリースのリリースペースだけでなく、バージョン名の命名についても厳格なポリシーを定めています。新しいリリースはGitLabブログで発表されます。

私たちの現在のポリシーは

• 現在の安定版 リリースのみのバグフィックスをバックポートすることです。
• 現在の安定版リリースに加えて、過去 2 回の月例リリースに対するセキュリティ修正をバックポートします。状況によっては (以下のセキュリティリリースで説明します)、パッチリリースプロセスや通常の月例リリースプロセスを使ってセキュリティ脆弱性にアドレスすることがあります。

まれに、リリースマネージャが例外として、直近の2つ以上の月例リリースにバックポートすることがあります。詳しくは、古いリリースへのバックポートを参照してください。

バージョニング

GitLabはリリースにセマンティック・バージョニングを使っています:(Major).(Minor).(Patch).

例えば、GitLabのバージョン13.10.6の場合：

• 13 はメジャーバージョンを表します。メジャーリリースは13.0.0ですが、しばしば13.0と呼ばれます。
• 10 はマイナーバージョンを表します。マイナーリリースは13.10.0ですが、しばしば13.10と呼ばれます。
• 6 はパッチ番号です。

13.10.11」のように、バージョン番号の任意の部分を複数の桁に分割することができます。

以下の表は、バージョンの種類とそのリリース時期を示しています。

アップグレードの推奨事項

最もセキュリティが高く機能が豊富な GitLab にアップグレードできるよう、最新の安定版リリースを実行することをお勧めします。最新の安定版リリースを実行できるように、私たちはアップデートプロセスをシンプルで信頼できるものにするよう努力しています。

私たちの毎月のリリースサイクルに従うことができない場合、考慮しなければならないケースがいくつかあります。バージョン間のアップグレードを安全に行うには、アップグレードパスのガイドに従ってください。

メジャーバージョンへのアップグレード

下位互換性のある変更とマイグレーションは、メジャーバージョン用に予約されています。アップグレードガイドをご覧ください。

パッチリリース

パッチリリースには、GitLabの現在の安定リリースバージョンのバグフィックスのみが含まれます。

この2つのポリシーがあるのは

1. GitLabにはCommunityとEnterpriseの2つのディストリビューションがあり、ソフトウェアのテスト/リリースに必要な作業量が2倍になります。
2. 2つ以上のリリースにバックポートすると、開発、品質保証、サポートのコストが高くなります。
3. パラレルバージョンをサポートすることで、時間が経つにつれて複雑さが増し、すべてのユーザーにアップグレードの課題をもたらすインクリメンタル・アップグレードを抑制することができます。 GitLabには、インクリメンタル・アップグレード（およびインストール）を可能な限りシンプルにするための専門チームがあります。
4. GitLabアプリケーションで作成される変更の数は多く、これが古いリリースへのバックポートを複雑にしています。 いくつかのケースでは、バックポートは新しい変更が通過するのと同じレビュープロセスを通過しなければなりません。
5. 古いリリースでテストを確実に通過させることは、場合によっては非常に困難であり、非常に時間がかかります。

パッチリリースに新機能を含めることは、セマンティックバージョニングを破壊することになるのでできません。セマンティックバージョニングの破壊は、様々な内部要件（例えば、組織のコンプライアンス、新機能の検証など）を遵守しなければならないユーザーに以下のような影響を与えます。

1. パッチバージョンに含まれるバグフィックスを活用するための迅速なアップグレードができない。
2. パッチバージョンに含まれるセキュリティ修正を活用するための迅速なアップグレードができない。
3. 安定したGitLabリリースだけでなく、すべてのパッチバージョンに対する広範なテストからなる要件。

戦略的なユーザーが正式にリリースされる前に機能をテストする必要がある場合、特定の機能を含むリリース候補版(RC) を作成することができます。これは極端な場合にのみ必要であり、リリース/タスクのイシュー・トラッカーにイシューを提起することで検討を依頼することができます。リリース候補版には他の機能や変更点が含まれていることに注意してください。リリース候補版は、GitLab.com にデプロイされたり公開されたりするコードと変わりません。

旧バージョンへのバックポート

複数の安定版リリースへのバックポートは、通常セキュリティリリースのために行われます。しかし、バグの深刻度によっては、バグ修正を複数の安定版リリースにバックポートする必要がある場合もあります。

変更をバックポートするかどうかの判断は、以下のすべてを考慮して、現在のリリース管理者の裁量で行われます：

1. バグの推定深刻度：現在の深刻度の定義に基づいて、ユーザーへの影響が最も大きいと考えられること。
2. バグの推定優先度：上記の推定深刻度に基づいて、影響を受けるすべてのユーザーに即時影響を与える。
3. データ損失やセキュリティ侵害が発生する可能性がある。
4. ユーザーが現在の安定版にアップグレードできないことが証明されたことにより、1つまたは複数の戦略的アカウントに影響を与える可能性があること。

上記のすべてを満たす場合、バックポートリリースは現在の安定版リリースと、2つ前の月例リリースに対して作成することができます。稀なケースとして、リリース管理者は、2 つ以上の過去の月例リリースへのバックポートを例外的に許可することがあります。例えば、13.0.0で発生した深刻なバグを修正した13.2.1 をリリースした場合、その修正を新しい13.0.xと13.1.x のパッチリリースにバックポートすることができます。

重要度3以下のリクエストは自動的に却下されることに注意してください。

複数の安定版リリースへのバックポートを検討してもらうためには、release/tasksissue trackerに課題を提起してください。

セキュリティリリース

セキュリティリリースはパッチリリースの中でも特別なもので、現在の安定版リリースに加え、2つ前の月例リリースのセキュリティ修正とパッチのみが含まれます。

非常に深刻なセキュリティ上の問題については、セキュリティ修正プログラムをさらに毎月リリースされるGitLabにバックポートするという前例があります。 この決定はケースバイケースで行われます。

状況によっては、パッチリリースプロセスや通常の月例リリースプロセスを使って脆弱性にアドレスすることを選択することもあります。この判断に影響を与える要因としては、悪用の可能性が非常に低いこと、影響が小さいこと、修正の複雑さ、安定性に対するリスクなどがあります。私たちは常に、高度で重大なセキュリティ問題にはセキュリティリリースでアドレスします。

詳細情報

こちらもご覧ください：

• リリース手順を説明したリリース文書
• 非推奨のガイドライン
• 責任ある情報開示方針