License

2011-08-02T04:26:29Z

Dougiamas: Replaced content with "{{Template:Moved_to_dev_docs}}"

Credits

2011-08-02T04:17:47Z

Dougiamas: Moved to dev docs

Updates

2011-07-01T21:57:06Z

Dougiamas: Replaced content with "{{Template:Moved_to_dev_docs}}"

Moodle versions

2011-07-01T21:45:55Z

Dougiamas: Replaced content with "{{Template:Moved to dev docs}}"

Upgrade warnings

2011-07-01T21:45:00Z

Dougiamas:

== Upgrade warnings==

If you reached this page from a warning during an upgrade from a stable version then it's probable that some of our branch changes have affected you.

From November 2010 until March 2011 we were using the "master" in git (HEAD in CVS) to work on the stable version of Moodle 2.0.x. In March 2011 we split the stable development to a separate branch called MOODLE_20_STABLE (see diagram below).

If you intend to stay with the most recent stable version of Moodle, then you need to switch your checkout over to use the MOODLE_20_STABLE branch. If you are using CVS, then use

cvs -q update -dPr MOODLE_20_STABLE

If you are using Git, then you must create new local branch in your clone that will track the remote stable branch and switch to it.

git branch --track local_20_STABLE origin/MOODLE_20_STABLE (1)
git checkout local_20_STABLE (2)
git pull (3)

Note that you can choose any name for the local branch. In the example above, the local branch is called local_20_STABLE. At the line (1) the new local branch is created and set to track the remote branch MOODLE_20_STABLE. At the line (2) we switch to the newly created branch. At the line (3) the git-pull command fetches recent changes from the upstream and merges them into your local branch. To update your Moodle next week, you can run just the line (3).

For more about how Moodle versions are managed in git and CVS, see our [[dev:Moodle_versions]] page.

Upgrading

2011-07-01T17:09:40Z

Dougiamas:

Moodle is designed to upgrade itself from one version to the next. The procedure is
# [[Site backup|Back up everything]].
# Replace the old version of the code with the new one.
# Visit the [[Site_administration_block#Notifications|administrator notifications]] link, which triggers Moodle to self-update.
These steps are explained in more detail below.

Sometimes there are specific considerations when upgrading to a particular version. See the [[dev:Releases|Releases page]] for more information on this. You also have to be more careful if you have installed additional plug-ins or customised the code.

See this tutorial if you are [http://ic.eflclasses.org/tutorials/howtoupgrademoodlewithcpanel.swf upgrading Moodle on cpanel]. It is a bit rough around the edges and is a little dated, but you should get the idea.

There is also a separate page about [[Ubuntu_Debian_Upgrades|upgrading Moodle if you installed it using the Ubuntu/Kubuntu/Debian package manager]].

__TOC__

When upgrading a Moodle installation you should follow these steps:

==Before you upgrade your site for real==

You are strongly advised to make a copy of your entire Moodle site onto another computer (see [[Moodle migration]]) and run the upgrade there to verify it will work.

==Check the requirements==
Spend some time re-reading the [[Installing Moodle | installation documentation]] and documentation for the new version. Check the system requirements for the target version you want to upgrade-to in ''Administration > Server > [[Environment]]''.
==Put your Site into Maintenance Mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | Maintenance Mode]] to stop any non-admin users from logging in.

== Backup important data ==
See [[Site backup]] for more specific information.

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, the SQL or Postgres database)

Experienced site administrators know that it is a best practice (a very good idea) to make a backup of any production system before a major upgrade. In fact, it is a good idea to automate your server to backup your Moodle installation daily. Most upgrades on sites that have used the standard Moodle packages (no contributed code and no little tweaks to the php files), will not have any major issues with the upgrade process.

:''TIP:'' One more time, "do not risk what you can not afford to lose": do regular backups, make sure it is really backed up and know how to restore a backup!

== Install the new Moodle software ==
Upgrading can be a simple process or a more complicated process. Sites that have not used contributed code and are migrating from say Moodle 1.x.1 to 1.x.3 '''should''' not have a problem. However, we still recommend that with any production server that you have made a successful backup of the MySQL database, the moodledata directory and the moodle program folders and files.

*Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. Review the backup section above.

=== Standard install package ===
Having read the cautions about backups, download a copy of the standard install package. Here is a set of simple instructions for an average site.
*It is probably a good idea to use the [[Site administration block]]>Server>Maintenance mode to prevent user activity as the site upgrades.
*Having moved your old Moodle software program files to another location, unzip or unpack the upgrade file so that all new the Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and [[Moodledata directory|moodledata]] if it needs to in the upgrade.
*Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
*If you had added any custom plugins or themes into your Moodle you can add them to the new code. It is important to check that you get the correct version for your new version of Moodle. You should check in the optional plugins database. Be particularly careful that you do not overwrite any code in the new version of Moodle. If you are upgrading to Moodle 2.0 or newer, note that all optional plugins and themes required a significant rewrite and most do not have 2.0 versions (yet).
*Use the notification link in the site administration to start the upgrade process. You will see a series of lines or screens indicating progress.
*After a successful upgrade, turn off the maintenance mode, so your users can get into the site.

=== Using a downloaded archive ===
In some installs, the site administrator may overwrite the Moodle code with a backup copy. Or create a new clean install copy of Moodle, then restore an archive (via a compressed file or parts of a saved set of Moodle code files and folders).

*Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new or "cleaned" installations. The best way is to rename the current Moodle code directory (for example rename "moodle" to "moodleold"), then unpack the new Moodle archive into the old location (for example, a new directory called "moodle").

====Linux====
mv moodle moodle.backup
tar xvzf moodle-1.1.tgz

Next, copy across your config.php, any other plugins such as custom themes, and your .htaccess file if you created one ('''check that optional/custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to

sudo chown www-data moodle/config.php

if necessary.

where www-data is whatever user the Apache user is on your system. This is often 'apache' or 'www'.
You can find out by doing 'ls -l' in your /var/www/moodle folder (or wherever your moodle site is)
and then looking at the owner and group.

so you may see something like

ls -l
...lots of lines...
-rw-r--r-- 1 apache system 784 Jun 28 2007 config.php
...lots more lines...

so the owner is apache and the group is system.

To replicate this on your new system you can do 'chown apache:system config.php'

or to do a whole group do

chown apache:system ./*

and recursively

chown -R apache:system ./*

=== Using CVS ===

You can use CVS for updating or upgrading your Moodle.
First you need to do a CVS checkout in your (empty) Moodle root directory.

You can use any of our [[CVS_for_Administrators#CVS_Servers|CVS Mirror servers]]. Just replace '''SERVER.cvs.moodle.org''' in the instructions below with the name of the mirror server you chose!.

====For Linux servers====

To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.

<nowiki>cvs -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle login</nowiki>
No password for anonymous, so just hit the Enter button.

Go to the directory where you want the Moodle root to come and type

<nowiki>cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -r MOODLE_18_STABLE moodle</nowiki>
(where MOODLE_18_STABLE is the desired version)

To update, just go into the Moodle root directory and update to the new files:

cvs update -dP
To update to a new version type in the following and change 18 to whatever newest version upgrade number is
cvs -Q update -dP -r MOODLE_18_STABLE

Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.

====For Windows servers====

You can use Tortoise CVS to do the initial checkout and the updates.

If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.

Do not forget to trigger the install process in the site administration block (see below).

=== Using Git ===

You can use [[Git]] for updating or upgrading your Moodle.
First you need to do a Git checkout in your (empty) Moodle root directory.

See [[Git for Administrators]] for further details.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

To do this just visit the [[Site administration block]] admin page (or ''<nowiki>http://example.com/moodle/admin</nowiki>'') and the "Notifications" link.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

:''TIP:'' Use the site administration block>Server>Maintenance mode to prevent users from changing data during the upgrade.
:''TIP:'' If you are running a large scale Moodle site (e.g. have more tha 10,000+ courses and 40,000+ users), make sure that you do your own performance profiling testing. Post a thread or check the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum] and check [[Tracker]] for potential issues.

== Verify the upgrade (optional) ==

If you wish to confirm that the database definitions in the upgraded database match the definitions of a new, clean install (which they should) you might like to look at [[Verify Database Schema]].

==Upgrading more than one version==

In general, it is recommended to upgrade via the newest of each major version of Moodle, for example 1.7 -> 1.9. An exception to this is when upgrading from 1.5 or 1.6, when it is recommended that 1.7 and 1.8 are skipped, in other words upgrade 1.5 -> 1.6 -> 1.9. (The main reason for this recommendation is that the default roles settings obtained when upgrading to 1.7 are not ideal for 1.8 onwards, 1.8 has problems with groups, etc.)

==See also==

*[[Installing Moodle]]
*[[Installation FAQ]]
*[[Upgrading to Moodle 1.6]]
*[[Upgrading to Moodle 1.8]]
*[[Upgrading to Moodle 1.9]]
*[[Upgrading to Moodle 2.0]]
*[[Environment]]
*[[Git]] Version control and upgrading
*Moodle.org [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]
*[http://ic.eflclasses.org/tutorials/howtoupgrademoodlewithcpanel.swf How to upgrade Moodle with cpanel tutorial] - screencasts of older Moodle/Cpanel install but useful (also, a very large file that will take some time to load).

Using Moodle.org forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs]
*[http://moodle.org/mod/forum/discuss.php?d=56915 Upgrading from 1.5.2 to 1.7]
*[http://moodle.org/mod/forum/discuss.php?d=56991 Upgrade nightmares.... any help appreciated]
*[http://moodle.org/mod/forum/discuss.php?d=62463 After upgrading i get "Your site may not be secure." msg]
*[http://moodle.org/mod/forum/discuss.php?d=104887 Best practices for QA]

[[Category:Installation]]

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:アップグレード]]
[[nl:Upgraden]]
[[zh:升级]]
[[pl:Aktualizacja]]
[[de:Aktualisierung von Moodle]]
[[ru:Обновление]]

Upgrading to Moodle 2.1

2011-07-01T16:58:50Z

Dougiamas: Replaced content with "{{Template:Moved to dev docs}}"

Help:Editing

Dougiamas:

Main page

2011-06-02T13:56:16Z

Dougiamas:

<p class="note">Welcome to the Moodle 2.0 documentation! '''[[MoodleDocs:News|STILL NEW AND UNDER CONSTRUCTION]]'''... </p>
{| class="mainpagetable" cellpadding="15"
|- valign="top"
| <h2>[[About Moodle]]</h2>
{{About Moodle items}}
| <h2>[[Getting your Moodle]]</h2>
{{Getting your Moodle items}}
| <h2>[[Managing a Moodle site]]</h2>
{{Managing a Moodle site items}}
|- valign="top"
| <h2>[[Managing a Moodle course]]</h2>
{{Managing a Moodle course items}}
| <h2>[[Learning and evaluation tools]]</h2>
{{Learning and evaluation tools items}}
| <h2>[[Managing content]]</h2>
{{Managing content items}}
|}
__NOTOC__

'''See the full [[Table of Contents]] for more detail'''

'''Join [http://moodle.org/mod/forum/view.php?id=5838 community discussion]'''

2011-04-27T05:32:11Z

Dougiamas:

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

Here are some terms we'll use in this document:
* STABLE = the next stable minor version of Moodle (eg 2.0.1, 2.0.2 ... etc)
* STABLE backlog = the queue of bugs to be fixed in STABLE (eg 2.0.x)
* DEV = the next major version of Moodle (eg 2.1, 2.2, 2.3 ... etc)
* DEV backlog = everything to be looked at for upcoming major versions (eg 2.X)

==Integration workflow in the tracker==

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

===Users===

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

===Developers===

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle.

===Component leads===

Component leads are developers with some responsibility for particular components (plugins or modules) in Moodle. They have the authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core, by adding their git branches to the integration queue. This can happen at any time.

===Integrators===

On Monday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===

On Tuesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

===Committers===

On Wednesday each week, committers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git, cvs, and download packages.

==Stable maintenance cycles==

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) and never any significant new features or database changes.

At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.

===Triage team===

Triagers evaluate new issues, making sure that they are labelled correctly. One of the most important jobs they do is to identify issues that should be fixed in the stable branch. These are added to the STABLE backlog with a priority ranging from "Trivial" up to "Blocker".

Other larger issues go into the DEV backlog for consideration as part of the next major release.

===Scrum team===

Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog (approx 30, but it varies) and starts working on solving them. The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code. The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress. Everything is documented publically in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

==Major release cycles==

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months: in June and December.

Each release can be different, but generally the cycles work like this:

===Define roadmap===

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code. The DEV backlog is also a factor.

Sometimes these might be based on earlier features, sometimes they may be evauluating something developed by a third party, sometimes it might be something completely new.

===Development team===

The DEV team (employed at Moodle HQ) work on major new features one or two at a time. The aim is always to try and finish things completely before moving on to the next features, as this helps to avoid delays in delivering a release on time.

All this code goes through the standard weekly integration workflow described above.

===QA Team===

Finally, in the last month before the release, a feature freeze is called (no new features can be added) and our QA team performs a full functional test of Moodle features (manually, one at a time) to make sure there are no regressions caused by new features.

The current list of functional tests is listed in the tracker in the [http://tracker.moodle.org/browse/MDLQA-1 MDLQA project]. This list of tests is extended on every release to include new developments.

==New feature development==

Major new features in Moodle usually should go through the following process.

===Specification===

The developer should create a detailed spec (here in Moodle Docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

You should also create an issue in the tracker (linking to your docs) to keep track of the project status.

===Community consultation===

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. The forums on moodle.org are good for this, but you could also blog/tweet about it etc.

You probably also want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

===Develop the code using git===

Develop your code on an open git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the [[Development:Coding|Moodle Coding Guide]]

===Submit the code for integration===

This is much the same as for any Moodle code. See the information about the integration workflow above.

[[Category:Developer|Process]]
[[Category:Quality Assurance]]
[[Category:Git]]

Development:Process

2011-04-27T05:31:34Z

Dougiamas: /* QA Team */

Development:Process

2011-04-27T05:29:51Z

Dougiamas: /* QA Team */

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

Here are some terms we'll use in this document:
* STABLE = the next stable minor version of Moodle (eg 2.0.1, 2.0.2 ... etc)
* STABLE backlog = the queue of bugs to be fixed in STABLE (eg 2.0.x)
* DEV = the next major version of Moodle (eg 2.1, 2.2, 2.3 ... etc)
* DEV backlog = everything to be looked at for upcoming major versions (eg 2.X)

==Integration workflow in the tracker==

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

===Users===

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

===Developers===

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle.

===Component leads===

Component leads are developers with some responsibility for particular components (plugins or modules) in Moodle. They have the authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core, by adding their git branches to the integration queue. This can happen at any time.

===Integrators===

On Monday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===

On Tuesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

===Committers===

On Wednesday each week, committers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git, cvs, and download packages.

==Stable maintenance cycles==

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) and never any significant new features or database changes.

At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.

===Triage team===

Triagers evaluate new issues, making sure that they are labelled correctly. One of the most important jobs they do is to identify issues that should be fixed in the stable branch. These are added to the STABLE backlog with a priority ranging from "Trivial" up to "Blocker".

Other larger issues go into the DEV backlog for consideration as part of the next major release.

===Scrum team===

Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog (approx 30, but it varies) and starts working on solving them. The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code. The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress. Everything is documented publically in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

==Major release cycles==

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months: in June and December.

Each release can be different, but generally the cycles work like this:

===Define roadmap===

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code. The DEV backlog is also a factor.

Sometimes these might be based on earlier features, sometimes they may be evauluating something developed by a third party, sometimes it might be something completely new.

===Development team===

The DEV team (employed at Moodle HQ) work on major new features one or two at a time. The aim is always to try and finish things completely before moving on to the next features, as this helps to avoid delays in delivering a release on time.

All this code goes through the standard weekly integration workflow described above.

===QA Team===

Finally, in the last month before the release, a feature freeze is called (no new features can be added) and our QA team performs a full functional test of Moodle features (manually, one at a time) to make sure there are no regressions caused by new features. This list of features is extended on every release to include new developments.

==New feature development==

Major new features in Moodle usually should go through the following process.

===Specification===

The developer should create a detailed spec (here in Moodle Docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

You should also create an issue in the tracker (linking to your docs) to keep track of the project status.

===Community consultation===

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. The forums on moodle.org are good for this, but you could also blog/tweet about it etc.

You probably also want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

===Develop the code using git===

Develop your code on an open git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the [[Development:Coding|Moodle Coding Guide]]

===Submit the code for integration===

This is much the same as for any Moodle code. See the information about the integration workflow above.

[[Category:Developer|Process]]
[[Category:Quality Assurance]]
[[Category:Git]]

Development:Process

2011-04-27T05:28:19Z

Dougiamas: Fixing headings

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

Here are some terms we'll use in this document:
* STABLE = the next stable minor version of Moodle (eg 2.0.1, 2.0.2 ... etc)
* STABLE backlog = the queue of bugs to be fixed in STABLE (eg 2.0.x)
* DEV = the next major version of Moodle (eg 2.1, 2.2, 2.3 ... etc)
* DEV backlog = everything to be looked at for upcoming major versions (eg 2.X)

==Integration workflow in the tracker==

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

===Users===

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

===Developers===

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle.

===Component leads===

Component leads are developers with some responsibility for particular components (plugins or modules) in Moodle. They have the authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core, by adding their git branches to the integration queue. This can happen at any time.

===Integrators===

On Monday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===

On Tuesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

===Committers===

On Wednesday each week, committers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git, cvs, and download packages.

==Stable maintenance cycles==

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) and never any significant new features or database changes.

At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.

===Triage team===

Triagers evaluate new issues, making sure that they are labelled correctly. One of the most important jobs they do is to identify issues that should be fixed in the stable branch. These are added to the STABLE backlog with a priority ranging from "Trivial" up to "Blocker".

Other larger issues go into the DEV backlog for consideration as part of the next major release.

===Scrum team===

Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog (approx 30, but it varies) and starts working on solving them. The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code. The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress. Everything is documented publically in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

==Major release cycles==

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months: in June and December.

Each release can be different, but generally the cycles work like this:

===Define roadmap===

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code. The DEV backlog is also a factor.

Sometimes these might be based on earlier features, sometimes they may be evauluating something developed by a third party, sometimes it might be something completely new.

===Development team===

The DEV team (employed at Moodle HQ) work on major new features one or two at a time. The aim is always to try and finish things completely before moving on to the next features, as this helps to avoid delays in delivering a release on time.

All this code goes through the standard weekly integration workflow described above.

===QA Team===

Finally, in the last weeks of the release, our QA team performs a full functional test of Moodle features (manually, one at a time) to make sure there are no regressions caused by new features. This list of features is extended on every release to include new developments.

==New feature development==

Major new features in Moodle usually should go through the following process.

===Specification===

The developer should create a detailed spec (here in Moodle Docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

You should also create an issue in the tracker (linking to your docs) to keep track of the project status.

===Community consultation===

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. The forums on moodle.org are good for this, but you could also blog/tweet about it etc.

You probably also want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

===Develop the code using git===

Develop your code on an open git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the [[Development:Coding|Moodle Coding Guide]]

===Submit the code for integration===

This is much the same as for any Moodle code. See the information about the integration workflow above.

[[Category:Developer|Process]]
[[Category:Quality Assurance]]
[[Category:Git]]

Development:Process

2011-04-26T16:42:29Z

Dougiamas: /* Core release cycles */

This document summarises the development processes used in developing Moodle.

==Terms==

Here are some terms we'll use in this document:
* STABLE = the next stable minor version of Moodle (eg 2.0.1, 2.0.2 ... etc) Note that database changes and new features are not allowed in STABLE
* STABLE backlog = the queue of bugs to be fixed in STABLE (eg 2.0.x)
* DEV = the next major version of Moodle (eg 2.1, 2.2, 2.3 ... etc)
* DEV backlog = everything to be looked at for upcoming major versions (eg 2.X)

==Development Processes==

We have a number of different processes that operate at different levels.

===Integration workflow in the tracker===

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

====Users====

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

====Developers====

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle.

====Component leads====

Component leads are developers with some responsibility for particular components (plugins or modules) in Moodle. They have the authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core, by adding their git branches to the integration queue. This can happen at any time.

====Integrators====

On Monday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

====Testers====

On Tuesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

====Committers====

On Wednesday each week, committers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git, cvs, and download packages.

===Stable maintenance cycles===

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) and never any significant new features or database changes.

At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.

====Triage team====

Triagers evaluate new issues, making sure that they are labelled correctly. One of the most important jobs they do is to identify issues that should be fixed in the stable branch. These are added to the STABLE backlog with a priority ranging from "Trivial" up to "Blocker".

Other larger issues go into the DEV backlog for consideration as part of the next major release.

====Scrum team====

Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog (approx 30, but it varies) and starts working on solving them. The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code. The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress. Everything is documented publically in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

===Major release cycles===

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months: in June and December.

Each release can be different, but generally the cycles work like this:

====Define roadmap====

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code. The DEV backlog is also a factor.

Sometimes these might be based on earlier features, sometimes they may be evauluating something developed by a third party, sometimes it might be something completely new.

====Development team====

The Dev team (employed at Moodle HQ) work on major new features one or two at a time. The aim is always to try and finish things completely before moving on to the next features, as this helps to avoid delays in delivering a release on time.

All this code goes through the standard weekly integration workflow described above.

====QA Team====

Finally, in the last weeks of the release, our QA team performs a full functional test of Moodle features (manually, one at a time) to make sure there are no regressions caused by new features. This list of features is extended on every release to include new developments.

===Feature development===

Major new features in Moodle usually should go through the following process.

====Specification====

The developer should create a detailed spec (here in Moodle Docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

You should also create an issue in the tracker (linking to your docs) to keep track of the project status.

====Community consultation====

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. The forums on moodle.org are good for this, but you could also blog/tweet about it etc.

You might also want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design and so on.

====Develop the code using git====

Develop your code on an open git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

====Submit the code for integration====

This is much the same as for any Moodle code. See the information about the integration workflow above.

[[Category:Developer|Process]]
[[Category:Quality Assurance]]
[[Category:Git]]

Development:Process

2011-04-26T16:40:43Z

Dougiamas: Major rewrite (draft)

This document summarises the development processes used in developing Moodle.

==Terms==

Here are some terms we'll use in this document:
* STABLE = the next stable minor version of Moodle (eg 2.0.1, 2.0.2 ... etc) Note that database changes and new features are not allowed in STABLE
* STABLE backlog = the queue of bugs to be fixed in STABLE (eg 2.0.x)
* DEV = the next major version of Moodle (eg 2.1, 2.2, 2.3 ... etc)
* DEV backlog = everything to be looked at for upcoming major versions (eg 2.X)

==Development Processes==

We have a number of different processes that operate at different levels.

===Integration workflow in the tracker===

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:

====Users====

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

====Developers====

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle.

====Component leads====

Component leads are developers with some responsibility for particular components (plugins or modules) in Moodle. They have the authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core, by adding their git branches to the integration queue. This can happen at any time.

====Integrators====

On Monday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

====Testers====

On Tuesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

====Committers====

On Wednesday each week, committers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git, cvs, and download packages.

===Stable maintenance cycles===

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) and never any significant new features or database changes.

At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.

====Triage team====

Triagers evaluate new issues, making sure that they are labelled correctly. One of the most important jobs they do is to identify issues that should be fixed in the stable branch. These are added to the STABLE backlog with a priority ranging from "Trivial" up to "Blocker".

Other larger issues go into the DEV backlog for consideration as part of the next major release.

====Scrum team====

Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog (approx 30, but it varies) and starts working on solving them. The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code. The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress. Everything is documented publically in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

===Core release cycles===

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months: in June and December.

Each release can be different, but generally the cycles work like this:

====Roadmap is defined====

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code. The DEV backlog is also a factor.

Sometimes these might be based on earlier features, sometimes they may be evauluating something developed by a third party, sometimes it might be something completely new.

====Dev team====

The Dev team (employed at Moodle HQ) work on major new features one or two at a time. The aim is always to try and finish things completely before moving on to the next features, as this helps to avoid delays in delivering a release on time.

All this code goes through the standard weekly integration workflow described above.

====QA Team====

Finally, in the last weeks of the release, our QA team performs a full functional test of Moodle features (manually, one at a time) to make sure there are no regressions caused by new features. This list of features is extended on every release to include new developments.

===Feature development===

Major new features in Moodle usually should go through the following process.

====Specification====

The developer should create a detailed spec (here in Moodle Docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

You should also create an issue in the tracker (linking to your docs) to keep track of the project status.

====Community consultation====

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. The forums on moodle.org are good for this, but you could also blog/tweet about it etc.

You might also want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design and so on.

====Develop the code using git====

Develop your code on an open git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

====Submit the code for integration====

This is much the same as for any Moodle code. See the information about the integration workflow above.

[[Category:Developer|Process]]
[[Category:Quality Assurance]]
[[Category:Git]]