• 機能はいつ非推奨になるのですか？
• 非推奨機能に対するコミュニティ貢献はどのように扱われますか？
• 機能はいつ削除/変更できますか？
• マイナーリリースの変更要求
• 非推奨及び削除文書の更新
• 関連ドキュメントの更新

廃止されるGitLabの機能

このページには、GitLabの機能を削除したり、破壊的な変更を加える方法や時期についての情報が含まれています。

このページで使われている用語の詳細については、用語をご覧ください。

機能はいつ非推奨になるのですか？

非推奨機能は、非推奨機能削除スケジュールでアナウンスされるべきです。

非推奨機能は、削除予定の3つ前のマイルストーンまでに発表されるべきです。

非推奨のコード変更を導入するマージリクエストに、非推奨のアナウンスを含めないでください。非推奨エントリを作成するには、別の MR を使用してください。非推奨エントリーの作成手順については、「非推奨」を参照してください。

非推奨機能に対するコミュニティ貢献はどのように扱われますか？

非推奨機能の開発者は、優先度 1 / 重大度 1 のバグ修正に限定されます。非推奨機能に対するコミュニティからの貢献は、マイルストーン計画中に優先順位がつけられることはありません。

しかし、GitLabではチームメンバーに権限を与えています。そのため、貢献に関連するチームのメンバーは、自分の判断でその貢献のレビューやマージに踏み切ることができます。

機能はいつ削除/変更できますか？

機能や設定はメジャーリリースでのみ削除/変更できます。

事前に非推奨とする必要があります。

APIの削除については、GraphQLおよびGitLab APIガイドラインを参照してください。

設定の削除については、Omnibusの非推奨ポリシーを参照してください。

バージョンアップとアップグレードの詳細については、リリースとメンテナンスのポリシーをご覧ください。

マイナーリリースの変更要求

GitLabのセルフマネージドパッケージは意味的にバージョン管理されており、メンテナンスポリシーに従っています。このプロセスは、ベータ版や実験的なものではなく、一般的に利用可能な機能やAPIに適用されます。

このメンテナンスポリシーは、ソフトウェア業界で広く使われている明確で予測可能なパターンを確立することで、お客様が破壊的な変化に備えることができるようにするために設けられています。多くのお客様にとって、GitLabはビジネスクリティカルなアプリケーションであり、予期せぬ変更は損害の原因となり、信頼を損ないます。

マイナーリリースで破たん的な変更を導入することは、私たちの顧客を混乱させる可能性があり、また、顧客が自分たちのビジネスに影響がないことを確認するためにマイナーリリースごとに破たん的な変更をチェックしなければならないランダム性の要素を導入するため、ポリシーに反します。これは、顧客がGitLabでビジネスを行うことをできるだけ簡単にするという私たちの目標に沿うものではなく、強く推奨されません。

破格の変更はコードベースにマージされた後にGitLab.comにデプロイされ、マイナーリリースケイダンスを尊重しません。予期せぬ変更によって影響を受ける可能性のあるお客様に迅速な解決を提供できるよう、カスタマーサポートチームと カスタマーサクセスチームには特に注意してお知らせください。

GitLabのポリシーを破ること、特にマイナーリリースで変更を反映させることは、変更を反映させることを遅らせることが、マイナーリリースで反映させることよりも顧客に与える悪影響が大きいとGitLabが判断した場合に限られます。例外が認められるかどうかを評価する最も重要なレンズは、顧客の結果です。

マイナーリリースでブレークチェンジを導入する場合、PMとEMは以下のプロセスに従って例外を申請する必要があります：

1. 製品のイシュー・トラッカーで、ブレークチェンジの例外テンプレートを使用して新しいイシューを作成します。
2. タイトルは以下のフォーマットに従ってくださいBreaking change exception: Description
3. 変更に伴う影響評価
   1. 影響を受ける顧客の数
   2. 破壊的な変更なしに同じ結果を得ることができますか？(例：撤去しない)
   3. 次のメジャーリリースまで、あるいはデータベースシナリオのような次のアップグレードストップまで、ブレークチェンジを待つことができますか？）
   4. その変更によって壊れる同じジョブを顧客が行うための代替案はありますか？
   5. 顧客にとって、代替案へのマイグレーションはどの程度困難ですか？マイグレーションプランはありますか？
4. コミュニケーション計画を提示し、目標とするマイナーリリースを含め、明確なタイムラインを設定してください。
5. サポートとカスタマーサクセスに通知し、関連する顧客と情報を共有できるようにします。
6. 開発担当副社長、製品管理担当副社長、カスタマーサポート担当副社長の承認者
7. CPOおよびCTOの承認者

非推奨及び削除文書の更新

deprecationsとremovalsのドキュメントはgitlab/data/deprecationsにあるYAMLファイルから生成されます。

YAML ファイルが追加、編集、削除されたときに deprecations と removals のページを更新するには、次のようにします：

1. コマンドラインからgitlab-org/gitlab プロジェクトの内部クローンに移動します。
2. data/deprecations の下にYAMLファイルを作成、編集、削除します。

3. 廃止予定と削除のドキュメントをコンパイルします：

   bin/rake gitlab:docs:compile_deprecations
   

4. 必要であれば、ドキュメントが最新であることを確認することができます：

   bin/rake gitlab:docs:check_deprecations
   

5. 更新されたドキュメントをコミットし、変更をプッシュします。
6. Deprecations and Removalsテンプレートを使ってマージリクエストを作成してください。

関連するハンドブックのページ

• https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes
• https://about.gitlab.com/handbook/marketing/blog/release-posts/#update-the-deprecations-and-removals-page

関連ドキュメントの更新

機能が非推奨になり削除されたら、関連ドキュメントを更新してください。