「開発:Moodleバージョン」の版間の差分

提供:MoodleDocs
移動先:案内検索
編集の要約なし
(done.)
 
(同じ利用者による、間の34版が非表示)
1行目: 1行目:
作成中です - [[利用者:Mitsuhiro Yoshida|Mitsuhiro Yoshida]] ([[利用者・トーク:Mitsuhiro Yoshida|トーク]])
==Moodleバージョンおよびブランチ==
==Moodleバージョンおよびブランチ==


Moodleのバージョニングスキームの理解により、私たちのリポジトリからあなたのコードを取得する際に役立ちます (例 [[:ja:アップグレード]])。正しいバージョンを知ることは私たちの [http://tracker.moodle.org トラッカ]へのバグ報告時にも有用です。
Moodleバージョニングスキームの理解により、あなたが私たちのリポジトリからコードを取得する際に役立ちます (例 [[:ja:アップグレード]])。正しいバージョンを知ることは私たちの [http://tracker.moodle.org トラッカ]へのバグ報告時にも有用です。
 
[[Image:versions.png|thumb|left|668px|Schema of Moodle source code branches, versions and maturity levels]]
<br clear="all" />


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


Moodleのバージョン番号は1.9.11または2.0.2のようにドットで区切られた3つの数字で構成されています。最初の2つの数字は1.9や2.0のように「メジャーバージョン」を表します。3番目の数字は同じメジャーバージョン内の「マイナバージョン」を区別するものです。新しいメジャーバージョンがリリースされた場合、マイナバージョンが0 (ゼロ) に設定されて開始します。つまり、Moodle 2.0.1はMoodle 2.0.0の最初のマイナバージョンということになります。
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 HQチームは2つの最新メジャーバージョンを保守しています (例外としてMoodle 1.9はより長くサポートされています)。


== バージョンおよびブランチ Versions and branches ==
== バージョンおよびブランチ ==


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


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


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


マイナバージョンは2ヶ月ごとにリリースされます。バグおよびセキュリティ問題の両方が修正されています。詳細および情報に関して[https://docs.moodle.org/dev/Releases#General_release_calendar リリース (英語)]ページをご覧ください。
マイナバージョンは2ヶ月ごとにリリースされます。バグおよびセキュリティ問題両方が修正されています。詳細および情報に関して[https://docs.moodle.org/dev/Releases#General_release_calendar リリース (英語)]ページをご覧ください。


2つのリリースの間にMoodle HQチームは最新の安定版へのアップデートを公開します。これらのアップデートは毎週、通常は木曜日に公開されます。これらは「ウィークリービルド」と呼ばれ、バージョンの小さな増分および [https://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=d8b0be3eb38b8b7991af470776cfb15d30d43de6 20200723] といった構築日により識別されます。They are known as ''weekly builds'' and are identified by a small increment in the version and a build date like [https://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=d8b0be3eb38b8b7991af470776cfb15d30d43de6 20200723]. That is a timestamp in a form YYYYMMDD when the weekly build was released. These weekly builds are labelled with a version number suffixed with a plus sign. So 3.9.1+ denotes some weekly build extending the 3.9.1 minor release.
2件のリリースの間にMoodle HQチームは最新の安定版へのアップデートを公開します。これらのアップデートは毎週、通常は木曜日に公開されます。これらは「ウィークリービルド」と呼ばれ、バージョンの小さな増分および「[https://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=d8b0be3eb38b8b7991af470776cfb15d30d43de6 20200723]」のような構築日により識別されます。
これはウィークリービルドがリリースされた時のYYYYMMDDの形式のタイムスタンプです。これらのウィークリービルドにはプラス記号の付いたバージョン番号が付けられています。つまり、3.9.1+ 3.9.1 のマイナリリースを拡張したウィークリービルドであることを意味します。


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


During its life cycle, the Moodle code branch goes through several maturity levels.
Moodleのライフサイクルの中でコードブランチはいくつかの成熟度レベルを通過します。
* At the beginning, the branch is considered as being in ''alpha'' state. During this period, new features are added to the branch. API and database structure may change as needed. These versions are intended mainly for developers as nothing is guaranteed (the version may or may not install and upgrade, for example).
* 最初のうちブランチは「アルファ」状態であるとみなされます。この期間中、ブランチに新しい機能が追加されます。APIおよびデータベース構造も必要に応じて変更される可能性があります。これらのバージョンは何も保証されないため、主に開発者向けです (例えばこのバージョンはインストールまたはアップグレードできるかもしれないし、できないかもしれません)
* When it is decided that no new feature will be added to the branch (so called feature freeze), ''beta'' maturity level is reached. Developers focus on testing, bugs fixing and stabilizing the branch.
* ブランチに新しい機能を追加しないという決定が下された場合 (いわゆる機能凍結)、「ベータ」成熟レベルに到達します。そして、開発者はテスト、バグフィックス、ブランチの安定化に注力します。
* When all known critical and blocker bugs are fixed and no new bugs are reported for some time of testing, a preview version of the branch can be released as so called release candidate. When the first release candidate version (RC1) has been published, ''release candidate'' maturity level is reached. During this period, several RC versions can be issued, for example 2.1RC1, 2.1RC2, 2.1RC3 etc.
*既知の致命的なバグやブロッカバグすべてが修正されて、しばらくのテスト実施後も新しいバグが発見されない場合、そのブランチのプレビュ版をリリース候補と呼んでリリースできるようになります。最初のリリース候補版 (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==
==バージョンナンバ ==
 
各プラグインのversion.phpファイルではプラグインが動作するために必要なMoodleの最小バージョンを指定できます。例えば以下のようになります:
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->version = 2011080200;
  $plugin->requires = 2011070101;
  $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).
==コアでバージョンナンバをインクリメントする方法==
私たちがMoodleのコアにおいてmasterからブランチを作成する場合、バージョンナンバもブランチに入れます。つまり、安定版ブランチのバージョンナンバはmaster (またはより高いブランチバージョン) より高くはならないということです。


The version number is constructed as '''YYYYMMDDRR.XX'''.
バージョンナンバは次のように構成されます: '''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)
* '''YYYYMMDD'''はブランチポイントの日付です。masterの場合、ブランチは発生していないため、現在の日付が設定されるべきです。それ以外の場合は変更すべきではありません (そのままにしておいてください)
* '''RR''' is the release increment. This is the incremental counter for changes on a single branch or day (if in master).
* '''RR'''はリリースインクリメントです。これは1つのブランチまたは1日 (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.
* '''XX'''はマイクロインクリメントです。この「マイクロインクリメント」は安定版ブランチで99以上のアップグレードステップ (RRインクリメント) が可能かもしれないことに私たちが気付いた後、導入されました。これはメインのバージョン番号ファイルでのみ使用される傾向があります。


===Rules for  stable branches===
===安定板ブランチのルール===


* If a 'micro increment' (.XX) exists
* マイクロインクリメント」(.XX) が存在する場合
** Developers should only increment the 'micro increment' 'XX'
** 開発者は「マイクロインクリメント」「XX」のみインクリメントする必要があります。
** The integration team reserve the use of 'RR' to branch between point releases.
** 統合チームはポイントリリース間の分岐に「RR」 を使用するよう留保します。
* If a 'micro increment' (.XX) does not exist
* マイクロインクリメント」(.XX) が存在しない場合
** Please increment the RR.
** 「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'''
* そのため、2013年2月6日には次のバージョン番号が設定されます。'''2013020600.00'''


===Why we branch versions ===
===なぜ私たちはバージョンをブランチ (分岐) するのか ===
Imagine the following problem scenario:
以下の問題のシナリオを想像してみてください:
# Moodle 2.4 is released, mod_forum is set to version 2012120300
# Moodle 2.4リリース後、mod_forumはバージョン2012120300に設定される。
# In master only, Eloy updates drops a DB field in an upgrade step and sets the moodle version to 2013010100
# マスタのみで「Eloyアップデート」はアップグレード段階でDBフィールドを落としてmoodleのバージョンを2013010100に設定する。
# 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!)
# 2.4.1およびmasterでDanはケイパビリティ定義の問題を修正して、両方のブランチのバージョンを201301020に設定する (注意: なんてことだ! 将来の2.4.x 全体のブランチの日付を間違って修正してしまった!)
# Moodle 2.5 is released and the mod_forum is set to version 2013060100
# Moodle 2.5がリリースされてmod_forumはバージョン2013060100に設定されます。
# After the release,  Helen updates her Moodle from Moodle 2.4.1 to 2.5.
# リリース後、Helenは彼女のMoodleをMoodle 2.4.1から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!'''
Danがステップ3で2.4.xのバージョンを2013010200に変更したことの意味はEloyのステップ2からのアップグレードが実行されないことを意味します。'''これは非常にまずい!''


===I know that there are no changes between STABLE and master, can I set the version number as the same? ===
===STABLEとmasterの間に変更がないのは理解できましたが、バージョン番号を同じにしても良いですか? ===
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]]
* [[リリース]]
* [[:en:Git for Administrators|Git for Administrators]]
* [[:en:Git for Administrators|Git for Administrators]]
* http://download.moodle.org
* http://download.moodle.org


[[es:Versiones de Moodle]]
[[es:Versiones de Moodle]]

2022年11月26日 (土) 15:00時点における最新版

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の間に変更がないのは理解できましたが、バージョン番号を同じにしても良いですか?

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

関連情報