• バージョニング
• アップグレードの推奨事項
  • メジャーバージョンへのアップグレード
  • バージョン12以降：メジャーアップグレードのための追加措置
  • アップグレードパスの例
  • 8.12より前のバージョンからのアップグレード
  • GitLabオールインワンLinuxパッケージリポジトリによるマルチステップのアップグレードパス
• パッチリリース
  • 旧バージョンへのバックポート
  • セキュリティリリース
• 詳細情報

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

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

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

• 任意の時点で現在の安定版リリースのみを対象としたバグフィックスをバックポートすること。 (パッチリリースを参照)
• 現在の安定版リリースに加えて、前々回の月例リリースにバックポートすること。 (セキュリティリリースを参照)

バージョニング

GitLabでは、リリースにセマンティック・バージョニングを採用しています：（メジャー）...（マイナー）...（パッチ）...。

例えば、GitLabバージョン12.10.6の場合。

• 12はメジャーバージョンを表します。 メジャーリリースは12.0.0でしたが、12.0と呼ばれることが多いです。
• 10はマイナーバージョンを表します。 マイナーリリースは12.10.0でしたが、12.10と呼ばれることが多いです。
• 6はパッチ番号を表します。

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

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

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

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

毎月のリリースサイクルに従うことができない場合は、いくつかのケースを考慮する必要があります。

1つのメジャーバージョンの中で、パッチバージョンやマイナーバージョンを飛び越えても問題ないとされています。 例えば、以下のような場合は問題ありません。

• 例えば、マイナーバージョンのアップグレードです。

  • 12.7.5->12.10.5
  • 11.3.4->11.11.1
  • 10.6.6->10.8.3
  • 11.3.4->11.11.8
  • 10.6.6->10.8.7
  • 9.2.3->9.5.5
  • 8.9.4->8.12.3

• 例えば、パッチのバージョンをアップグレードします。

  • 12.0.4->12.0.12
  • 11.11.1->11.11.8
  • 10.6.3->10.6.6
  • 11.11.1->11.11.8
  • 10.6.3->10.6.6
  • 9.5.5->9.5.9
  • 8.9.2->8.9.6

注）OmnibusGitLab Linuxパッケージのバージョンごとの変更点は、Omnibus GitLabのドキュメントに記載されています。

注：Omnibus GitLab Linuxのパッケージをローカルにダウンロードして、手動でインストールする方法が紹介されています。

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

メジャーバージョンのアップグレードには、より注意が必要です。 後方互換性のない変更や移行は、メジャーバージョンでのみ行われます。 メジャーバージョン間のシームレスなアップグレードを保証するものではありません。 次のメジャーバージョンに進む前に、メジャーバージョン内で利用可能な最新のマイナーバージョンにアップグレードすることをお勧めします。 これにより、後方互換性のない変更や廃止事項に対処し、次のメジャーリリースへのアップグレードを成功させることができます。

また、新しいメジャーバージョンにアップグレードする前に、バックグラウンドでの移行が完全に完了していることを確認することも重要です。background_migrationキューの現在のサイズを確認するには、Check for background migrations before upgradingを参照してください。

GitLabインスタンスにGitLab Runnersが関連付けられている場合は、GitLab Runnersをアップグレードして、アップグレードされたGitLabのマイナーバージョンに合わせることが非常に重要です。 これは、GitLabのバージョンとの互換性を確保するためです。

バージョン12以降：メジャーアップグレードのための追加措置

バージョン12以降では、追加の手順が必要となります。 より重要な移行は、メジャーリリースのアップグレード時に発生する可能性があります。

これらを成功させるために

1. メジャーバージョンのジャンプ中に最初のマイナーバージョン（x.0.x）にインクリメントする。
2. 新しいリリースへのアップグレードを進めてください。

例：11.5.x->11.11.x->12.0.x->12.10.x->13.0.x

アップグレードパスの例

下の表に例を示します。

8.12より前のバージョンからのアップグレード

• 8.11.x以前のバージョン：8.17.7にアップグレードする前に、特別に8.12.0 にアップグレードしなければならない場合があります。 この問題は、ある問題で報告されています。
• GitLabに統合されたバージョン8.0以前のCI変更点。

GitLabオールインワンLinuxパッケージリポジトリによるマルチステップのアップグレードパス

Linuxのパッケージマネージャは、インストールやアップグレードの際に、利用可能な最新バージョンのパッケージをインストールすることをデフォルトとしています。 最新のメジャーバージョンに直接アップグレードすることは、多段階のアップグレードパスを必要とする古いGitLabバージョンでは問題となります。

複数のバージョンにまたがるアップグレードパスをたどる場合は、各アップグレードごとに、パッケージマネージャのインストールまたはアップグレードコマンドで、目的のGitLabバージョン番号を指定します。

例：

# apt-get (Ubuntu/Debian)
sudo apt-get upgrade gitlab-ee=12.0.12-ee.0
# yum (RHEL/CentOS 6 and 7)
yum install gitlab-ee-12.0.12-ee.0.el7
# dnf (RHEL/CentOS 8)
dnf install gitlab-ee-12.0.12-ee.0.el8
# zypper (SUSE)
zypper install gitlab-ee=12.0.12-ee.0

パッチリリース

パッチリリースには、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つの月次リリースに対してバックポートリリースを作成することができます。 たとえば、11.0.0で導入された深刻なバグを修正した11.2.1をリリースした場合、その修正プログラムを新しい11.0.xと11.1.xのパッチリリースにバックポートすることができます。

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

セキュリティリリース

セキュリティリリースは、特別な種類のパッチリリースで、現在の安定版リリースに加えて、前々回の月次リリースのセキュリティ修正とパッチ（下記参照）のみが含まれています。

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

詳細情報

リリース記事をチェック

毎月、GitLabのメジャーリリースまたはマイナーリリースを発表しています。 それらのリリース記事の最後には、「Deprecations」「Removals」「Important notes on upgrade」の3つのセクションがあります。 これらには、以下が含まれます。

• 例えば、8.12ではElasticsearchのインデックスを再作成する必要があります。 古いバージョンのGitLabを8.12以上にアップグレードする場合は、この作業が必要になります。
• サポートしているソフトウェアのバージョンの変更（GitLab 13でIE11のサポートを終了するなど）。

渡しているメジャーバージョンとマイナーバージョンをすべて確認する必要があります。

リリース手順の詳細については、リリースドキュメントをご覧ください。 また、当社の責任ある情報開示方針もお読みください。