バージョン ライフサイクル

This page is a translated version of the page Version lifecycle and the translation is 100% complete.

MediaWiki は「継続的なインテグレーション」という開発モデルで運営されており、ソフトウェアの変更は定期的にウィキペディアなどのウィキメディアのウェブサイト群に実際に展開されます。

理論的には、新しいメジャー リリースは半年単位で発行され、リリース ブランチは最初のリリース時点で最長1年間、セキュリティの更新を受け続けます。しかし、時間的な制約やコード ベースの急速なリファクタリングのため、古くなったリリースを永久にサポートすることはできませんし、ライフ サイクルが終了したリリースにはセキュリティの更新や重大な更新は適用されません。

リリース マネージャーの Tim Starling をはじめとする MediaWiki の開発者は、ウィキ運用者が mediawiki-announce メーリング リストを購読することを強く推奨します。これに参加するとすべてのリリースの告知を受け取れるため、自分のウィキを確実に最新のバージョンのソフトウェアで実行し続けることができます。同じアナウンスが mediawiki-lwikitech-l の各メーリング リストにも投稿されます。

バージョンとライフサイクル終了時期

完全な履歴については、w:MediaWiki version history を参照してください。
バージョン 状態 リリース ライフサイクル終了
1.43.x (LTS) 将来の長期間サポートバージョン
1.42.x 現行の安定バージョン
1.41.x 旧バージョン
1.40.x 廃止されたバージョン
1.39.x (LTS) 現行の長期間サポートバージョン
1.38.x 廃止されたバージョン

上記の表で「廃止されたバージョン」としているバージョンでは、列挙されていないバージョンと同様に、セキュリティ上の修正を受けられません。 これには、列挙されている最も古いバージョンよりも古いすべてのバージョンも含まれます。 致命的なセキュリティ上の脆弱性や、その他の重大な不具合を抱えているおそれがあり、データの消失や破壊もありえます。 リリース マネージャーは、実稼働環境では、上記の表の現行の「安定バージョン」「旧バージョン」「長期間サポート バージョン (LTS)」のいずれかのバージョンのみを使用することを強く推奨します

Special:MyLanguage/MediaWiki 1.19Special:MyLanguage/MediaWiki 1.20Special:MyLanguage/MediaWiki 1.21Special:MyLanguage/MediaWiki 1.22Special:MyLanguage/MediaWiki 1.23Special:MyLanguage/MediaWiki 1.24Special:MyLanguage/MediaWiki 1.25Special:MyLanguage/MediaWiki 1.26Special:MyLanguage/MediaWiki 1.27Special:MyLanguage/MediaWiki 1.28Special:MyLanguage/MediaWiki 1.29Special:MyLanguage/MediaWiki 1.30Special:MyLanguage/MediaWiki 1.31Special:MyLanguage/MediaWiki 1.32Special:MyLanguage/MediaWiki 1.33Special:MyLanguage/MediaWiki 1.34Special:MyLanguage/MediaWiki 1.35Special:MyLanguage/MediaWiki 1.36Special:MyLanguage/MediaWiki 1.37Special:MyLanguage/MediaWiki 1.38Special:MyLanguage/MediaWiki 1.39Special:MyLanguage/MediaWiki 1.40Special:MyLanguage/MediaWiki 1.41Special:MyLanguage/MediaWiki 1.42Special:MyLanguage/MediaWiki 1.43
MediaWiki のリリース タイムライン
  •   アルファ版の開発
  •   リリース版の開発
  •   安定版リリース
  •   長期間サポート リリース (LTS: Long-term support)

リリースの方針

  • それぞれのポイント リリースは、国際化ファイルの更新やあらゆるバグ修正を含んでいます。 新機能がポイントリリースにバックポートされることはありませんし、サポート対象には必ずしも一般的に同梱された拡張機能や外装 が含まれるとは限りません。
  • メジャー リリース6か月ごとに公開されます。
  • マイナー リリース (セキュリティ パッチ、メッセージ翻訳のバックポート、全般的なバグ修正を含む) は四半期ごとに公開されます。
  • 長期間サポート リリース (LTS: Long Term Support) は、2 年ごとに公開されます。LTS のサポート期間は 1 年ずつ重なっています。例えば、1.23 のサポートは2017年5月まででした。その前年に 1.27 がリリースされたため、移行先の LTS として利用でき、1年間を移行期間として確保できます。
  • リリース ノートは、何が変更されたかを確認するための基礎となるものです。 ボランティアで運営されているプロジェクトの性質上、今後6~12か月の間に何が起こる予定かを確実に言うことはできません。
バージョン 1.36 以降、MediaWiki は 2 つの主要な LTS リリース からのアップグレードをサポートすることのみを保証しています (phab:T259771 を参照)。 MediaWiki の古いバージョンからのアップグレードは、複数のステップで実行する必要があります。 これは、1.34 以前のバージョンから 1.42 にアップグレードする場合、最初に 1.34 のウィキを 1.35 (または 1.39) にアップグレードし、さらに 1.35 (または 1.39) から 1.42 にアップグレードする必要があることを意味します。

リリース日程

このタイムラインは、新しいバージョンがリリースされるまでに必要なことのスケジュールです。ここでは、実際のリリース日は、「T」(リリースの「時間」の意味) と接尾辞「-#」(「リリースの # 週間前」の意味) で示されます。

相対的な日程 作業内容
T - 7 1週間後にリリースブランチを作成すると発表します。進行中の機能を完成させるために必要なものは、それまでに必ずマージするようにお願いしましょう。Phabricator で「MW-X.XX-release」を作成します。
T - 6 コアおよびすべての拡張機能のブランチを Gerrit 内に作成します。
T - 5 X.XX-rc.0 タグを適用し、初回のリリース候補をリリースします。
T - 4 あらゆるバグ報告を収集し、それらをメーリングリスト内で要約します。
T - 3 X.XX-rc.1 タグを適用し、2 つめのリリース候補をリリースします。tarball に新たに追加することが提案されている拡張機能は、この時点までにすべて含めるべきです。 この時点以降、拡張機能は変更されません。
T - 2 新しいバグ報告を収集し、修正をマージし、誤って含まれていた不完全な新機能を取り消します。X.XX-rc.2 タグを適用し、3 番目のリリース候補をリリースします。
T - 1 前の段階を繰り返し、X.XX-rc.final をタグ付けし、リリースします。 この時点以降、バックポートは受理されません。
T リポジトリに X.XX のタグを付けて、リリースします。

拡張機能のライフサイクルの管理

ほとんどの MediaWiki のインストレーションには、かなりの数の拡張機能が含まれています (ウィキメディアのウィキでは大抵、拡張機能は約 140 個に達します)。 HEAD 開発バージョンが、MediaWiki コアの安定版や旧安定版ではまだ利用できない機能に依存している場合、拡張機能の保守管理/バグ修正や適切なバージョンの選択は困難を伴います。

拡張機能のメンテナーには MediaWiki のバージョンごとに拡張機能の各バージョンの git ブランチを設定するよう強く推奨します。 (詳細は互換性#MediaWiki拡張機能 を参照。) ウィキメディアの git リポジトリにホストされている拡張機能では、それらのブランチ (MediaWiki 1.30 ならブランチ名 REL1_30) は新しい MediaWiki バージョンが分岐されると自動でマスターから生成されます (前提として拡張機能の master が常時、MediaWiki master と互換性があるはずという認識)。 しかし、拡張機能のメンテナーは HEAD だけでなく旧安定版や安定版のバグも修正していただけると助かります (必要なら旧ブランチに修正をバックポートすることで)。

これらの規則の目標は、MediaWiki をインストールする人や組織が、簡単な方法で最新リリースおよび一致する拡張機能をインストールすることに依存できるようにすることです (例: 1.20.x のコアに合わせるには、Git のブランチ REL1_20 を使用)。 また、tarball や zip ファイルが関連性のない予測不可能な名前になるのを回避できます。

関連項目