Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Overview: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 1: Line 1:
A lot of people ask how the development of Moodle operates.  This page should give you a working overview that should help in understanding a lot of other developer documentation.
A lot of people ask how the development of Moodle operates.  This page should give you a working overview that should help in understanding a lot of other developer documentation.


(This page is under early construction)
(This page is under early construction, your help in linking to other pages from here would be welcome!)


==The key players==
==The key players==
Line 26: Line 26:
Generally a cycle works like this:
Generally a cycle works like this:
;Rapid Development:Long period of several months adding code to the HEAD version of Moodle.  At the same time, all fixes that don't involve database changes or radical core changes are backported to the last two or three stable branches.
;Rapid Development:Long period of several months adding code to the HEAD version of Moodle.  At the same time, all fixes that don't involve database changes or radical core changes are backported to the last two or three stable branches.
;Head Freeze:At some point Martin declares a freeze on new work for a short period to stabilise the core.  All database changes and radical core changes need to have explicit permission from Martin.  This period may be one or two weeks.
;Head Freeze:At some point Martin Dougiamas declares a freeze on new work for a while to stabilise the core.  All database changes and all major core changes need to have explicit permission from Martin.  All developers should be wrapping up work on new features and fixing bugs in new code.  This period may be 1 or 2 weeks.
;Beta period:Once things get fairly stable, Martin declares a BETA version and this point is marked on HEAD as MOODLE_XX_BETA (eg MOODLE_19_BETA).  Install packages are generated from this for wider testing and feedback via the tracker.  The freeze continues.  This testing period may be anywhere from 2 to 6 weeks.
;Beta period:Once the HEAD version becomes fairly stable, Martin declares a BETA version and this point is marked on HEAD as MOODLE_XX_BETA (eg MOODLE_19_BETA).  Install packages are generated daily from the latest version for wider testing and feedback via the tracker.  The freeze continues, testing and bug fixing continues.  This testing period may be anywhere from 2 to 6 weeks.
;Major release:When the core code passes all the testing, the MOODLE_XX_BETA flag is moved up as a branchpoint, and a new stable branch named MOODLE_XX_STABLE is created.  Packages are created, and the release is announced.
;Major release:When the core code passes all the testing we can throw at it, the MOODLE_XX_BETA flag is moved up to mark the current point as a branch point, and a new stable branch named MOODLE_XX_STABLE is created.  Packages are created, and the release is announced.


Then it all starts again!
Then it all starts again!
Line 35: Line 35:


==Coding Standards==
==Coding Standards==
The full [[Coding|Coding Guide]] gives all the details, but here are some of the major things  your code needs to hit:
===XMLDB===
===XMLDB===
All our database schema are created using the XML install.php files, and upgraded using database-agnostic commands in upgrade.php files.  Any version of any part of Moodle can be smoothly upgraded to any later version in this fashion (on a wide variety of supported databases).
===XHTML===
===XHTML===
All output from Moodle must be compliant with XHTML Strict 1.0, and also compliant with all common accessbility guidelines (such as W3C WAG). 
===Forms===
===Forms===
All forms should use the Moodleforms library if possible.  This results in a standardised accessible output that designers can style constently and well.
===Parameters===
All parameters should be checked using require_param() and optional_param() which will safely clean all incoming data for use and provide defaults to your code.  Moodleforms will do this automatically for you.
===Output===
All textual output should be output using the format_text or format_string functions.  This will ensure that text is cleaned and filtered appropriately.
===Access===
===Access===
All permissions-checking should use the "Access library" to check against current capabilities.  The most common function you'll use is has_capability() which checks the permissions of the current user in an efficient way to see if they are allowed to do this specific operation.  Do not check for specific roles in your code (eg teacher/student) as that will make your code useless.
===Other core libraries===
===Other core libraries===
The other major libraries you should get familiar with are:
# moodlelib.php - a useful bin of all kinds of useful functions and constants.
# datalib.php - all the functions you need to interface with the database
# weblib.php - all the functions you'll need to create and output XHTML
===Plugins===
===Plugins===
Moodle has about 22 different types of plugins last time I counted.  Plugins can generally be self-contained in a single directory containing scripts, images, stylesheets and language files all in one package that can be dropped into the Moodle script directory in the right place.  After that the admin just needs to visit the admin page to installthem.
Most plugins work in one of two ways, they either provide a lib.php filled with common functions and some scripts with standard names, or they subclass a proto-plugin and override a few method functions to achieve their goals. 
The best way to learn is to pick an example from the core code that is similar to what you want to do and start playing with it.  There are also some template plugins to help get you started.


==Development processes==
==Development processes==
Not all Moodle development happens exactly like this, but they really should. :-)
===Major Development===
===Major Development===
====Make a proposal====
A major development is a significant piece of new code, adding new functionality to Moodle.
 
====Make sure it's a good idea====
Firstly, you should look at the roadmap and talk the idea over with some Moodle developers to see if someone else is working on it already and whether others think the general idea has merit.  Use the forums if you wish, or whatever means you have.  If you have a client, you may need to work with them to work out what they REALLY want (perhaps it isn't actually a new development for Moodle).
 
====Create a specification in Moodle Docs====
====Create a specification in Moodle Docs====
Start a new page in the Moodle Docs wiki, similar to https://docs.moodle.org/en/Development:Grades.  Your page should outline the database table design, the GUI, the hows and whys etc.  Include as much detail as you need (even mock screenshots) but try to keep it clear and logically organised.
====Seek and absorb community feedback====
====Seek and absorb community feedback====
Post about the new page in the appropriate forums on [Using Moodle http://moodle.org/course/view.php?id-5] to help draw attention to it and to stimulate some discussion around your development.  The more feedback you have the better, especially if it includes a wide variety of users (developers, teachers, students etc).
Edit your page in response to the feedback, or invite people to do so themselves.  try to evolve the specification into something that all users are happy with.  Sometimes it's worth working harder to find the "best" way to do something without adding Yet Another Option.
====Set up tasks in the Moodle Tracker====
====Set up tasks in the Moodle Tracker====
Once the specification has settled down, it's time to start work.  Create a new task for yourself in the Moodle Tracker, and add sub-tasks in roughly chronological order for all the different parts of the job.  This not only helps you keep trck of where you are, but allows the community to "watch you" develop and to help you where they can.  If there are different people working on different parts, you can assign subtasks to different people.  It's really very convenient to use once you get the hang of it.
====Use CVS and link commits to Tracker====
====Use CVS and link commits to Tracker====
If possible, develop the code in an open code repository (and preferably Moodle CVS!).  If you need CVS write access to the core code or the contrib repository, contact support@moodle.com with details.  Gaining access to the main core code is quite difficult, but we are generally very free with access to the contrib area.
Every time you make a commit, include a detailed message about the new code and always include a Moodle Tracker bug number (eg MDL-7777).  This wil ensure that the Moodle Tracker is able to detect your commit and attach it to the relevant bug report.
====Comment on milestones in forums and tracker====
====Comment on milestones in forums and tracker====
If you hit a major milestone, or want testers to try something, feel free to post about it in the relevant forum on Using Moodle.  The more people you can attract to look and try out your code the better it will be, trust me.
====Respond to bug reports====
====Respond to bug reports====
Of course you need to listen to your users (well, most of them :-)).  Encourage people to file bugs, and fix them.  If you need help setting up a project category in the tracker contact support@moodle.com.  This will ensure that all your bugs are easy to find and to track.


===Minor Development===  
===Minor Development===  

Revision as of 15:45, 24 September 2007

A lot of people ask how the development of Moodle operates. This page should give you a working overview that should help in understanding a lot of other developer documentation.

(This page is under early construction, your help in linking to other pages from here would be welcome!)

The key players

Martin Dougiamas
Martin is the lead developer of Moodle. Generally he tries to facilitate democracy and meritocracy but occasionally has to make executive decisions on things.
Moodle HQ
The mostly-Australian team of developers who are directly funded by the Moodle project to work full-time on core developments. Developers include Martin Dougiamas (moodler), Yu Zhang (lazyfish), Petr Skoda (skodak), Nicolas Connault, Helen Foster (wildgirl) and occasionally Eloy Lafuente (stronk7), Jamie Pratt (jamiesensei).
Catalyst
The team of developers working for Moodle clients via Catalyst Ltd in New Zealand, resulting in a lot of core development. Developers include Martin Langhoff, Penny Leach (mjollnir), Matt Clarkson, and Donal McMullan.
Open University
The team of developers working on Moodle implementations at Open University in the UK. Developers include Tim Hunt, Sam Marshall, Nick Freear, Thanh Le and Jenny Gray.

There are many other people contributing to Moodle in many ways, these are just the main groups currently working on core development.

Moodle versions

Moodle major releases occur roughly 6 months or more apart, on no fixed schedule. Each major release increments the version number by 0.1. Minor releases (no new features, just fixes) on each stable branch can occur at any time, whenever enough bug fixes have been made to justify them. The full details can be seen in the [Release notes].

The current development version is always on the trunk of CVS (ie HEAD), while stable branches are split off for every major version (eg MOODLE_18_STABLE).


Release cycles

Generally a cycle works like this:

Rapid Development
Long period of several months adding code to the HEAD version of Moodle. At the same time, all fixes that don't involve database changes or radical core changes are backported to the last two or three stable branches.
Head Freeze
At some point Martin Dougiamas declares a freeze on new work for a while to stabilise the core. All database changes and all major core changes need to have explicit permission from Martin. All developers should be wrapping up work on new features and fixing bugs in new code. This period may be 1 or 2 weeks.
Beta period
Once the HEAD version becomes fairly stable, Martin declares a BETA version and this point is marked on HEAD as MOODLE_XX_BETA (eg MOODLE_19_BETA). Install packages are generated daily from the latest version for wider testing and feedback via the tracker. The freeze continues, testing and bug fixing continues. This testing period may be anywhere from 2 to 6 weeks.
Major release
When the core code passes all the testing we can throw at it, the MOODLE_XX_BETA flag is moved up to mark the current point as a branch point, and a new stable branch named MOODLE_XX_STABLE is created. Packages are created, and the release is announced.

Then it all starts again!

Quality control

Coding Standards

The full Coding Guide gives all the details, but here are some of the major things your code needs to hit:

XMLDB

All our database schema are created using the XML install.php files, and upgraded using database-agnostic commands in upgrade.php files. Any version of any part of Moodle can be smoothly upgraded to any later version in this fashion (on a wide variety of supported databases).

XHTML

All output from Moodle must be compliant with XHTML Strict 1.0, and also compliant with all common accessbility guidelines (such as W3C WAG).

Forms

All forms should use the Moodleforms library if possible. This results in a standardised accessible output that designers can style constently and well.

Parameters

All parameters should be checked using require_param() and optional_param() which will safely clean all incoming data for use and provide defaults to your code. Moodleforms will do this automatically for you.

Output

All textual output should be output using the format_text or format_string functions. This will ensure that text is cleaned and filtered appropriately.

Access

All permissions-checking should use the "Access library" to check against current capabilities. The most common function you'll use is has_capability() which checks the permissions of the current user in an efficient way to see if they are allowed to do this specific operation. Do not check for specific roles in your code (eg teacher/student) as that will make your code useless.


Other core libraries

The other major libraries you should get familiar with are:

  1. moodlelib.php - a useful bin of all kinds of useful functions and constants.
  2. datalib.php - all the functions you need to interface with the database
  3. weblib.php - all the functions you'll need to create and output XHTML


Plugins

Moodle has about 22 different types of plugins last time I counted. Plugins can generally be self-contained in a single directory containing scripts, images, stylesheets and language files all in one package that can be dropped into the Moodle script directory in the right place. After that the admin just needs to visit the admin page to installthem.

Most plugins work in one of two ways, they either provide a lib.php filled with common functions and some scripts with standard names, or they subclass a proto-plugin and override a few method functions to achieve their goals.

The best way to learn is to pick an example from the core code that is similar to what you want to do and start playing with it. There are also some template plugins to help get you started.


Development processes

Not all Moodle development happens exactly like this, but they really should. :-)

Major Development

A major development is a significant piece of new code, adding new functionality to Moodle.

Make sure it's a good idea

Firstly, you should look at the roadmap and talk the idea over with some Moodle developers to see if someone else is working on it already and whether others think the general idea has merit. Use the forums if you wish, or whatever means you have. If you have a client, you may need to work with them to work out what they REALLY want (perhaps it isn't actually a new development for Moodle).

Create a specification in Moodle Docs

Start a new page in the Moodle Docs wiki, similar to https://docs.moodle.org/en/Development:Grades. Your page should outline the database table design, the GUI, the hows and whys etc. Include as much detail as you need (even mock screenshots) but try to keep it clear and logically organised.

Seek and absorb community feedback

Post about the new page in the appropriate forums on [Using Moodle http://moodle.org/course/view.php?id-5] to help draw attention to it and to stimulate some discussion around your development. The more feedback you have the better, especially if it includes a wide variety of users (developers, teachers, students etc).

Edit your page in response to the feedback, or invite people to do so themselves. try to evolve the specification into something that all users are happy with. Sometimes it's worth working harder to find the "best" way to do something without adding Yet Another Option.

Set up tasks in the Moodle Tracker

Once the specification has settled down, it's time to start work. Create a new task for yourself in the Moodle Tracker, and add sub-tasks in roughly chronological order for all the different parts of the job. This not only helps you keep trck of where you are, but allows the community to "watch you" develop and to help you where they can. If there are different people working on different parts, you can assign subtasks to different people. It's really very convenient to use once you get the hang of it.

Use CVS and link commits to Tracker

If possible, develop the code in an open code repository (and preferably Moodle CVS!). If you need CVS write access to the core code or the contrib repository, contact support@moodle.com with details. Gaining access to the main core code is quite difficult, but we are generally very free with access to the contrib area.

Every time you make a commit, include a detailed message about the new code and always include a Moodle Tracker bug number (eg MDL-7777). This wil ensure that the Moodle Tracker is able to detect your commit and attach it to the relevant bug report.

Comment on milestones in forums and tracker

If you hit a major milestone, or want testers to try something, feel free to post about it in the relevant forum on Using Moodle. The more people you can attract to look and try out your code the better it will be, trust me.

Respond to bug reports

Of course you need to listen to your users (well, most of them :-)). Encourage people to file bugs, and fix them. If you need help setting up a project category in the tracker contact support@moodle.com. This will ensure that all your bugs are easy to find and to track.


Minor Development

Create a new issue in the tracker

Attach a patch

Promote the patch

How can you become a Moodle developer?