開発:Moodleバージョン

作成中です - Mitsuhiro Yoshida (トーク)

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

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

Schema of Moodle source code branches, versions and maturity levels

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

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 のマイナリリースを拡張したウィークリービルドであることを意味します。

ソースコード成熟度 Source code maturity levels

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

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

Version numbers

Each plugin's version.php file can specify a minimum version of Moodle required for the plugin to work, for example

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

For the version numbers related to each release, see the Releases page.

How to increment version numbers in core

In Moodle core, when we branch from master, we also branch version numbers. That means that no version number in a stable branch should ever be higher than on master (or a higher branched version).

The version number is constructed as YYYYMMDDRR.XX.

• YYYYMMDD is the date of the branching point. If on master, a branch has not happened, so it should be set to the current date. Otherwise it should not be changed (left as it was)
• RR is the release increment. This is the incremental counter for changes on a single branch or day (if in master).
• XX is the micro increment. This 'fraction increment' was introduced when after we realised that it might be possible to have more than 99 upgrade steps on a stable branch (in the RR increment). It tends to only be used in the main version number file.

Rules for stable branches

• If a 'micro increment' (.XX) exists
  • Developers should only increment the 'micro increment' 'XX'
  • The integration team reserve the use of 'RR' to branch between point releases.
• If a 'micro increment' (.XX) does not exist
  • Please increment the RR.

Rules for master

• You must increment the whole version number to the current date.
• So, on 6th February 2013, the version number is set to: 2013020600.00

Why we branch versions

Imagine the following problem scenario:

1. Moodle 2.4 is released, mod_forum is set to version 2012120300
2. In master only, Eloy updates drops a DB field in an upgrade step and sets the moodle version to 2013010100
3. In 2.4.1 and master, Dan fixes a problem in a capability definition and sets the version in both branches to 2013010200. (note: Oh no! we've incorrectly changed the branching date for the entire future 2.4.x!)
4. Moodle 2.5 is released and the mod_forum is set to version 2013060100
5. After the release, Helen updates her Moodle from Moodle 2.4.1 to 2.5.

The implications of Dan changing the 2.4.x version to 2013010200 in step 3, means that Eloy's upgrade step from 2 will never get run. This is very bad!

I know that there are no changes between STABLE and master, can I set the version number as the same?

Not for core plugins, sorry. There are too many developers working on the same code and it prevents accidents if we avoid doing this for core.

See also

• Releases
• Git for Administrators
• http://download.moodle.org