Development Levels

A module development level is stored in the development_status manifest key. This is consistent with the terminology used on  PyPi, and the allowed values arbe the same as the ones used by PyPi: alpha, beta, production/stable, and mature.

For better visibility of the development level, it should be highlighted in the module README. If the new module documentation structure is adopted (using a DESCRIPTION.rst and other companion documentation files), this will be automatically done by a nightly script, that compiles all the separate RST documents into a single README.rst file.

Modules in all development status are hosted alongside, in the same repositories and branches. You will find Beta modules alongside Stable ones. so make sure to
check the README of manifest before deciding to use a module in production.

A module’s Development Status can be different for different versions. A “mature” or “stable” module in a version can start as “stable” or “beta” in the next branch, as a step towards maturity.

All modules, regardless of their development status, will be published on PyPi and on the Odoo AppStore.

Next we describe what each development status means, what can be expected by users, and what are the requirements for modules to be assigned each maturity level.

Beta modules

Beta modules allow for the incubation of OCA Stable modules. They enable the work to be split into several smaller pull requests, that are easier to review and make it easier to divide the work between several people.

Each pull request is an iteration providing a correct set of features. The corresponding code should always pass TravisCI checks and should have at least one peer review.

Since a “beta” module is a work in progress toward a “stable” module, it is not be suitable for use in production. The design and implementation may change without notice in incompatible ways, the development work may halt, and it is even possible that it may be abandoned and deleted from the repository.

The suggested module incubation workflow looks like this:

1. Create a “WIP” Issue for the module, used to coordinate the work and different PRs related to it. It should state the final goal and describe the next work units to be done.

2. Create the PRs implementing the work units described in the WIP Issue. They must pass CI tests and peer review.

3. Once contributors feel that the module is complete, promotion to “stable” status can be proposed through a PR changing the development_status manifest key.

This workflow can also be extended to support a functional design stage, prior to the implementation:

• Before the “WIP” Issue, an “RFC” issue (complemented by a Google Doc or similar, if necessary) can be created for an initial discussion of the scope, desired features and the implementation design outline.

• Once a “WIP” Issue is created, a first PR can create the skeleton of the new module, including the basic DESCRIPTION.rst, and a SPECS.rst file for the specifications and technical design.

As a summary, “beta” modules:

• Must at all times follow the OCA coding standards and ensure TravisCI green builds.

• Must be correctly installed by the OCA Runbot, without conflicting with other installed modules, allowing people to try them
  

• Are recommended to have a “WIP” Issue to list the pending tasks and coordinate the work around them.

Stable modules

Stable modules are adequate for production use, and meet all the original OCA quality requirements: green CI build passing all current mandatory checks, and peer reviewed by at least two other people.

They have an “API stable” policy similar to the Odoo policy for stable branches, ensuring that extensions won't break, but more permissive, allowing for feature additions and improvements.

As a summary, “stable” modules:

• Must at all times follow the OCA coding standards and ensure TravisCI green builds.

• Must be correctly installed by the OCA Runbot, without conflicting with other installed modules, allowing people to try them.

• Must have some tests (no minimum coverage percentage required).

• Must not depend on Beta modules.

• Two peer reviews and a review period of at least five days are needed for merge. The review period can be shorter if three or more reviewers approve the PR.
  

Mature modules

Mature modules not only meet the stable criteria, but are also known to be actively maintained.  Usually these are modules in use in several deployments, and maintained by more than one party. They typically survived major version changes, having version ports, and there is a reasonable expectation for this to happen in future major versions.

Mature modules:

• Must meet all "Stable" module criteria, 

• Are recommended to also exists for at least one previous Odoo version.

• Must have tests with at least 80% of code coverage, and have no lint beta message warnings.

• Must be stable across Odoo versions: in case that significant changes are made to the data model, automatic migration OpenUpgrade scripts are provided. API breakages must be documented clearly, and be accompanied with a change in the major version number.

• Must have at least 2 contributors.

• Must depend only on Mature quality level modules.

• Must not have relevant overlap with existing Mature modules (unless a good justification is given, evaluated by the relevant PSC).