開発:Moodleバージョン

Moodleバージョンおよびブランチ

Moodleバージョニングスキームの理解により、あなたが私たちのリポジトリからコードを取得する際に役立ちます (例 ja:アップグレード)。正しいバージョンを知ることは私たちの トラッカへのバグ報告時にも有用です。

メジャおよびマイナバージョン

Moodleのバージョン番号は1.9.11または2.0.2のようにドットで区切られた3つの数字で構成されています。最初の2つは1.9や2.0のように「メジャーバージョン」を表します。3番目の数字は同じメジャーバージョン内の「マイナバージョン」を区別するものです。新しいメジャーバージョンがリリースされた場合、マイナバージョン「0」 (ゼロ) から開始します。つまり、Moodle 2.0.1はMoodle 2.0.0の最初のマイナバージョンということになります。

一般的にMoodle HQチームは2つの最新メジャーバージョンを保守しています (例外としてMoodle 1.9はより長くサポートされています)。

バージョンおよびブランチ

Moodle開発者はソースコード管理 (SCM) システム「Git」をコードの変更履歴追跡のために使用しています。多くのSCMと同様にGitにおける変更の履歴は「ブランチ」と呼ばれるもので表現されます。ブランチはソースコードの変更点のラベル付けされたシーケンスと考えることができます。

Moodleの各メジャーバージョンにはブランチが作成されます。すべてのMoodle 1.9バージョンはMOODLE_19_STABLEブランチから、すべてのMoodle 2.0バージョンはMOODLE_20_STABLEブランチから提供されます。また、masterと呼ばれるメイン開発ブランチがあり、次期バージョンのための変更内容を保持しています。現時点ではmasterブランチの変更内容はMoodle 2.1リリースに含まれる予定です。

リリース

バージョン2.0以降、Moodleは約半年ごとの新しいメジャーバージョンのリリースを目標としています。スケジュールについては ロードマップ ページをご覧ください。

マイナバージョンは2ヶ月ごとにリリースされます。バグおよびセキュリティ問題両方が修正されています。詳細および情報に関してリリース (英語)ページをご覧ください。

2件のリリースの間にMoodle HQチームは最新の安定版へのアップデートを公開します。これらのアップデートは毎週、通常は木曜日に公開されます。これらは「ウィークリービルド」と呼ばれ、バージョンの小さな増分および「20200723」のような構築日により識別されます。 これはウィークリービルドがリリースされた時のYYYYMMDDの形式のタイムスタンプです。これらのウィークリービルドにはプラス記号の付いたバージョン番号が付けられています。つまり、3.9.1+ は 3.9.1 のマイナリリースを拡張したウィークリービルドであることを意味します。

ソースコード成熟度

Moodleのライフサイクルの中でコードブランチはいくつかの成熟度レベルを通過します。

• 最初のうちブランチは「アルファ」状態であるとみなされます。この期間中、ブランチに新しい機能が追加されます。APIおよびデータベース構造も必要に応じて変更される可能性があります。これらのバージョンは何も保証されないため、主に開発者向けです (例えばこのバージョンはインストールまたはアップグレードできるかもしれないし、できないかもしれません)。
• ブランチに新しい機能を追加しないという決定が下された場合 (いわゆる機能凍結)、「ベータ」成熟レベルに到達します。そして、開発者はテスト、バグフィックス、ブランチの安定化に注力します。
• 既知の致命的なバグやブロッカバグすべてが修正されて、しばらくのテスト実施後も新しいバグが発見されない場合、そのブランチのプレビュ版をリリース候補と呼んでリリースできるようになります。最初のリリース候補版 (RC1) が公開された時点で「リリース候補」の成熟度に到達します。この間、2.1RC1、2.1RC2、2.1RC3等、いくつかのRCバージョンが公開される場合があります。
• 最後に新しいメジャバージョンがリリースされて、このブランチは「安定版」の成熟度に達します。今後、このブランチではデータベース構造およびAPIは変更されません。対応するMOODLE_xx_STABLEの作成後、マイナバージョンおよびウィークリビルドはそこから作成されます。

バージョンナンバ

各プラグインのversion.phpファイルではプラグインが動作するために必要なMoodleの最小バージョンを指定できます。例えば以下のようになります:

$plugin->version = 2011080200;
$plugin->requires = 2011070101;

各リリースに関連するバージョンナンバに関してリリースページをご覧ください。

コアでバージョンナンバをインクリメントする方法

私たちがMoodleのコアにおいてmasterからブランチを作成する場合、バージョンナンバもブランチに入れます。つまり、安定版ブランチのバージョンナンバはmaster (またはより高いブランチバージョン) より高くはならないということです。

バージョンナンバは次のように構成されます: YYYYMMDDRR.XX

• YYYYMMDDはブランチポイントの日付です。masterの場合、ブランチは発生していないため、現在の日付が設定されるべきです。それ以外の場合は変更すべきではありません (そのままにしておいてください)。
• RRはリリースインクリメントです。これは1つのブランチまたは1日 (masterの場合) の変更に対する増分カウンタです。
• XXはマイクロインクリメントです。この「マイクロインクリメント」は安定版ブランチで99以上のアップグレードステップ (RRインクリメント) が可能かもしれないことに私たちが気付いた後、導入されました。これはメインのバージョン番号ファイルでのみ使用される傾向があります。

安定板ブランチのルール

• マイクロインクリメント」(.XX) が存在する場合
  • 開発者は「マイクロインクリメント」「XX」のみインクリメントする必要があります。
  • 統合チームはポイントリリース間の分岐に「RR」 を使用するよう留保します。
• マイクロインクリメント」(.XX) が存在しない場合
  • 「RR」をインクリメントしてください。

マスタのルール

• あなたはバージョン番号全体を現在の日付にインクリメントする必要があります。
• そのため、2013年2月6日には次のバージョン番号が設定されます。2013020600.00

なぜ私たちはバージョンをブランチ (分岐) するのか

以下の問題のシナリオを想像してみてください:

1. Moodle 2.4リリース後、mod_forumはバージョン2012120300に設定される。
2. マスタのみで「Eloyアップデート」はアップグレード段階でDBフィールドを落としてmoodleのバージョンを2013010100に設定する。
3. 2.4.1およびmasterでDanはケイパビリティ定義の問題を修正して、両方のブランチのバージョンを201301020に設定する (注意: なんてことだ! 将来の2.4.x 全体のブランチの日付を間違って修正してしまった!)。
4. Moodle 2.5がリリースされてmod_forumはバージョン2013060100に設定されます。
5. リリース後、Helenは彼女のMoodleをMoodle 2.4.1から2.5へアップデートします。

Danがステップ3で2.4.xのバージョンを2013010200に変更したことの意味はEloyのステップ2からのアップグレードが実行されないことを意味します。'これは非常にまずい!

STABLEとmasterの間に変更がないのは理解できましたが、バージョン番号を同じにしても良いですか?

申し訳ございません、コアプラグインには適用しないでください。同じコードで作業している開発者が多過ぎるため、コアに適用しない方が事故を防げます。

関連情報

• リリース
• Git for Administrators
• http://download.moodle.org