バージョン ライフサイクル
| MediaWiki |
|---|
|
| より古いバージョン |
| バージョン ライフサイクル |
MediaWiki は「継続的なインテグレーション」という開発モデルで運営されており、ソフトウェアの変更は定期的にウィキペディアなどのウィキメディアのウェブサイト群に直接展開されます。
理論的には、新しいメジャー リリースは半年ごとに発行され、リリース ブランチは最初のリリースから最長1年間、セキュリティ更新を受け続けます。しかし、時間的な制約やコード ベースの急速なリファクタリングのため、古いリリースを永久にサポートすることはできず、サポート期間が終了したリリースにはセキュリティおよび重要な更新は適用されません。
リリース マネージャーの Tim Starling をはじめとする MediaWiki の開発者は、ウィキ運用者が mediawiki-announce メーリング リストを購読することを強く推奨します。これに参加するとすべてのリリースの告知を受け取れるため、自分のウィキを確実に最新のバージョンのソフトウェアで実行し続けることができます。同じアナウンスが mediawiki-l と wikitech-l の各メーリング リストにも投稿されます。
バージョンとライフサイクル終了時期
| バージョン | 状態 | リリース | ライフサイクル終了 |
|---|---|---|---|
| 1.46.x | 将来のバージョン | ||
| 1.45.x | 現行の安定バージョン | ||
| 1.44.x | 旧安定バージョン | ||
| 1.43.x (LTS) | 従来の安定版で現行の長期間サポートバージョン | ||
| 1.42.x | 廃止されたバージョン | ||
| 1.41.x | 廃止されたバージョン | ||
| 1.40.x | 廃止されたバージョン | ||
| 1.39.x (LTS) | 旧版の長期間サポートバージョン | ||
| 1.38.x | 廃止されたバージョン |
上記の表で「廃止されたバージョン」としてマークされているバージョンや、まったく記載されていないバージョンには、セキュリティ修正が適用されません。 これには、列挙されている最も古いバージョンよりも古いすべてのバージョンも含まれます。 重大なセキュリティの脆弱性や他の大きなバグが含まれている可能性があり、データ損失やデータの破損の危険が伴うことがあります。 リリース マネージャーは、実稼働環境では、上記の表の現行の「安定バージョン」「旧バージョン」「長期間サポート バージョン (LTS)」のいずれかのバージョンのみを使用することを強く推奨します。
- アルファ版の開発
- リリース版の開発
- 安定版リリース
- 長期間サポート リリース (LTS: Long-term support)
リリースの方針
- それぞれのポイント リリースは、国際化ファイルの更新やあらゆるバグ修正を含んでいます。 新機能がポイントリリースにバックポートされることはありませんし、サポート対象には必ずしも一般的に同梱された拡張機能や外装が含まれるとは限りません。
- メジャー リリースは6か月ごとに公開されます。
- マイナー リリース (セキュリティ パッチ、メッセージ翻訳のバックポート、全般的なバグ修正を含む) は四半期ごとに公開されます。
- 長期間サポート リリース (LTS: Long Term Support) は、2 年ごとに公開されます。LTS のサポート期間は 1 年ずつ重なっています。例えば、1.23 のサポートは2017年5月まででした。その前年に 1.27 がリリースされたため、移行先の LTS として利用でき、1年間を移行期間として確保できます。
- リリース ノートは、変更内容を確認するための基礎となるものです。ボランティアが運営するプロジェクトの性質上、今後6～12か月間に何が起こる予定かを確実に述べることはできません。
リリース日程
このタイムラインは、新しいバージョンがリリースされる前に必要なことのスケジュールです。ここでは、実際のリリース日は「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 ファイルが関連性のない予測不可能な名前になるのを回避できます。
関連項目
- MediaWiki の互換性情報、特に PHP と MySQL に関する情報
- 安定版インターフェイスの方針
- Generators on WikiApiary - MediaWiki のバージョン間の使用状況統計