GitLabのリリースおよびメンテナンスポリシー

Delivery Groupは、メンテナンスポリシーのオーナーであり、リクエストされた更新をすべて承認する必要があります。これは、当社のDRIモデルに従ったもので、お客様に対して予測可能性を提供するために導入されています。

GitLabには、バージョン命名規則、およびメジャー、マイナー、パッチリリースのリリース頻度を管理する厳格なポリシーがあります。新しいリリースは、GitLabブログで発表されます。

現在のポリシーは次のとおりです:

バグ修正のバックポートは、常にonly the current stable release（現在の安定版リリースのみ）に対して行います。下記のパッチリリースを参照してください。
セキュリティ修正のバックポートは、to the previous two monthly releases in addition to the current stable release（現在の安定版リリースに加えて、過去2回の月次リリース）に対して行います。状況によっては（下記のパッチリリースに概要を記載）、セキュリティの脆弱性への対応が、バックポートなしで、現在の安定版リリースのみ、または通常の月次リリースプロセスで行われる場合があります。

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

バージョニング

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

たとえば、GitLabバージョン18.3.2の場合:

18はメジャーバージョンを表します。メジャーリリースは18.0.0でしたが、18.0と呼ばれることがよくあります。
3はマイナーバージョンを表します。マイナーリリースは18.3.0でしたが、18.3と呼ばれることがよくあります。
2はパッチ番号を表します。

バージョン番号のどの部分も、複数の桁に増やすことができます（例：18.3.11）。

次のテーブルに、バージョンタイプとそのリリースケイデンスを示します:

バージョンタイプ	説明	ケイデンス
メジャー	大幅な変更の場合、または下位互換性のない変更がパブリックAPIに導入された場合。	年1回。次のメジャーリリースはGitLab 19.0で、2026年5月21日に予定されています。GitLabは、デフォルトでは、毎年5月にメジャーリリースをスケジュールしています。
マイナー	新しい下位互換性のある機能がパブリックAPIに導入された場合、マイナー機能が導入された場合、または一連のより小さな機能がロールアウトされた場合。	毎月、各月の第3木曜日にスケジュールされています。
パッチ	正しくない動作を修正する下位互換性のあるバグ修正の場合。パッチリリースを参照してください。	月2回、月次のマイナーリリースの前週の水曜日と翌週の水曜日にスケジュールされています。

メンテナンスバージョン

以下のGitLabのリリースバージョンは現在メンテナンスされています:

18.7 （バグとセキュリティ修正）
18.6 （セキュリティ修正）
18.5 （セキュリティ修正）

今後のパッチリリースでメンテナンスされるバージョンを探しているGitLabチームのメンバーは、内部delivery: Release Information GrafanaダッシュボードのPatch Release InformationセクションにあるRelease Versionsパネルを参照してください。アクティブな月次リリース日がアクティブなパッチリリース日よりも前の場合、上記のメンテナンスバージョンのリストとは異なります。

バグ修正のバックポートは現在の（最初の）バージョンに対してメンテナンスされ、セキュリティ修正のバックポートはすべてのバージョンに対してメンテナンスされます。

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

最も安全で機能豊富なGitLabエクスペリエンスにアップグレードできるように、最新の安定版リリースを実行することをすべてのユーザーに推奨します。最新の安定版リリースを確実に実行できるように、アップデートプロセスを信頼性の高いものにするための取り組みを続けています。

月次リリースサイクルに従うことができない場合は、考慮すべき点がいくつかあります。バージョン間で安全にアップグレードするには、アップグレードパスガイドに従ってください。

Linuxパッケージのバージョン固有の変更ドキュメントは、以下で入手できます:

Linuxパッケージをローカルにダウンロードし、手動でインストールするための手順が用意されています。

LinuxパッケージにバンドルされたPostgreSQLをアップグレードする手順ガイドは、別途文書化されています。

メジャーバージョンをアップグレードする

下位互換性のない変更と移行は、メジャーバージョンで行われます。詳細については、GitLabアップグレードプランを作成するを参照してください。

パッチリリース

パッチリリースには、GitLabの現在の安定版リリースのbug fixes（バグ修正）、および現在の安定版リリースに加えて、過去2回の月次リリースへのsecurity fixes（セキュリティ修正）が含まれます。

これらのポリシーが実施されている理由は次のとおりです:

GitLabにはCommunityおよびEnterpriseのディストリビューションがあり、ソフトウェアのテスト/リリースに2倍の作業量が必要です。
古いリリースへのバックポートは、開発、品質管理、およびサポートコストが高くなります。
バージョンを並行してサポートすると、段階的なアップグレードが避けられ、時間の経過とともに複雑さが増し、すべてのユーザーにとってアップグレードが難しくなります。GitLabには、段階的なアップグレード（およびインストール）を可能な限り簡単にするための専任のチームがあります。
GitLabアプリケーションで行われた変更の数は多く、古いリリースへのバックポートは一層複雑になっています。多くの場合、バックポートは新しい変更が行うのと同じレビュープロセスを経る必要があります。
古いリリースでテストに合格することを保証することは、場合によってはかなりの課題であり、そのため非常に時間がかかります。

セマンティックバージョニングを破ることになるため、パッチリリースに新機能を含めることはできません。セマンティックバージョニングを破ると、さまざまな内部要件（たとえば、組織のコンプライアンス、新機能の検証など）を順守する必要があるユーザーに次の影響があります:

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

非常に深刻なセキュリティイシューについては、セキュリティ修正をさらに以前のGitLabリリースバージョンにバックポートした前例があります。この決定は、個々のケースに基づいて行われます。

状況によっては、バックポートなしで、アクティブな最新の安定版リリースのみを更新することにより、通常の月次リリースプロセスを使用して脆弱性に対処することを選択する場合があります。この決定に影響を与える要因には、悪用される可能性が非常に低いこと、脆弱性の影響が低いこと、セキュリティ修正の複雑さ、および安定性に対する最終的なリスクなどがあります。重大度が高く、クリティカルなセキュリティイシューには常に、パッチリリースで対応します。

古いリリースへのバックポート

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

変更のバックポートを実行するかどうかの決定は、現在のリリースマネージャーの裁量で行われ、次のすべての要素に基づきます:

バグの推定重大度: 現在の重大度の定義に基づく、ユーザーへの最大の影響度。
バグの推定優先度: 前述の推定重大度に基づく、影響を受けるすべてのユーザーに対する即時的な影響。
データ損失および/またはセキュリティ漏洩が発生する可能性。
ユーザーが現在の安定版バージョンにアップグレードできないため、1つ以上の戦略的アカウントに影響を与える可能性。

前述のリストにある項目のすべてが満たされた場合、現在の安定版リリース、および過去2回の月次リリースに対してバックポートリリースを作成できます。まれに、リリースマネージャーが例外として、過去2回以上の月次リリースをバックポートすることがあります。たとえば、13.0.0で発生した重大なバグの修正を含む13.2.1をリリースする場合、修正を新しい13.0.xおよび13.1.xパッチリリースにバックポートできます。

重大度3以下のリクエストは自動的に拒否されます。

複数の安定版リリースへのバックポートを考慮するようリクエストするには、リリース/タスクイシュートラッカーでイシューを提起してください。

詳細情報

次のドキュメントも参照してください:

リリース手順を説明したリリースドキュメント
開発ドキュメントの非推奨ガイドライン。
責任ある開示ポリシー