The official repository contains three branches only. These are:

• next, the code that is unstable and waits to enter master.
• master, the code that will go into the next stable release.
• maint, the code of the latest stable version.

Patches are applied upwards. This means that it should be developped and applied for the oldest branch possible, either maint or master and next in last resort. Then the patch is merged upwards to the other branches. So if the patch was applied to maint, it will then be merged in master, and finally in next.

When a developer needs to make changes, he creates a new branch from master and names in a way that describes the features he wants to implement (e.g. storage or session).

Once the developer has finished working on the feature, he asks a maintainer with push rights to the main repository to review his work and merge it in the next branch. Then he deletes the now useless branch.

Once the changes are deemed stable enough, the maintainer should merge next into master.

Code reviews are important. The following guidelines detail the review process for the different merge stages of the project.

The feature code is reviewed by one maintainer prior to being merged into next.

The branch next needs to be reviewed by at least two maintainers prior to being merged into master.

All the full-time core developers must agree on the code and documentation before releasing.

Patches must be reviewed by at least two maintainers on all three main branches and applied to them.