FAQ Release process

Introduction

This page describe what is the build and release process of a new stable version of Dolibarr ERP CRM (manufacturing process or chaine de fabrication in french).

A new version is build following different steps:

A development period -> A freeze / beta period -> A final stable version (See page Category:RoadMap for definition of a Freeze / Beta version)

This is description of the 3 steps.

Development

First step is development of software. Sources can be download from GitHub at https://github.com/Dolibarr/dolibarr

Any developer can download sources and work on his side using git and submit a request to ask to include his changes to the official sources.

See the FAQ Get or update project with GIT for more information on how to do this.

Continuous interation

Each time a new request to include a change is submitted, Continuous Integration Tests are done before the change is validated.

Continuous integration Test are included into official sources into directory *tests*. They are run on the Travis platform and can be analyzed here: https://travis-ci.org/Dolibarr/dolibarr/

If a test fails, it will not be validated (see next step).

Validation of new changes

Only people with the grade Dolibarr Yoda can accept to include changes into official development sources. Permissions for this are granted on GitHub

See Dolibarr roles for the list of people with this grade.

Beta period

When enough changes are included into version, and according to planning, the Dolibarr Yoda decide to start the beta. Starting from this point, no new features are added.

See page Category:RoadMap for standard planning of new versions and rules that define what kind of code can be modified or not during a beta period.

The minimal and maximal version of PHP, MySQL are also defined at the start of the beta. The policy to decide if a minimal version of PHP is as follow:

The minimal version of PHP is increased if the number of user using the current minimal version of Dolibarr is lower than 2%
OR if a new external library (that Dolibarr depends on) is no more compatible with the current minimal version of PHP and need a higher version.

If there is no reason to increase the minimal version of PHP, it should not be done: Project rule is that end users must be encouraged to use the highest compatible PHP version but they must not be forced to upgrade their infrastructure if we can avoid it. So, end users can upgrade their system according to security concerns only for example, and not according to a pace imposed by an unfounded decision (with no mandatory reason).

Generating the packages is done using the packaging tool makepack_dolibarr.pl. See the next chapter for detailed operation done by this tool.

The packaging of final releases

When beta period end (no more serious bugs are reported and opened), the Dolibarr Yoda decide to start the freeze of final version. The name of the version is define to a value X.Y.Z.

Note: Only a Dolibarr Yoda can make this process.

Firstly, final Unit Tests are run. If 1 test is wrong, process is stopped here and go back to beta phase.

Once all tests are ok, the following steps are done automatically using the packaging tool makepack_dolibarr.pl :

The tool generate (or suggest the command to generate) the ChangeLog file. This file is commited with sources.
The tool generates the file filelist-X.Y.Z.xml than contains the list of files of the version with a MD5 signature and value of version. This file is commited with sources.
The tool add a Tag that is the name of version (so X.Y.Z) on all files of the official source repository. So starting from now, all files for the dedicated version are known and won't change anymore.
The tool build all official distribution packages. Content of such packages match the content of the signature file since it is build during same process. The following packages are built:
- Package .zip (the main package)
- Package .tgz
- Autoinstaller Doliwamp .exe
- Autoinstaller for Debian/Ubuntu DoliDeb .deb
- Autoinstaller for Redhat, linuxmint, mandriva DoliRpm .rpm
The tool upload the generated signature file filelist-X.Y.Z.xml on the official Dolibarr server. This file can be read by any installed application to check the integrity of the version (even one byte modified will change the signature).
The tool upload the generated packaged into the official Dolibarr archive server to have them archived also in a binary form. This archives can be read from page https://www.dolibarr.org/files/stable/
The tool upload the generated packaged into the mirror archive servers hosted at https://www.sourceforge.net. This is a mirror hosting, official references remain the Dolibarr archive area and are hosted by the Dolibarr team so at https://www.dolibarr.org/files/stable/.
The release is also created on https://GitHub.com/Dolibarr/dolibarr
Then people of the Dolibarr community send announcements on different channels (www.dolibarr.org, forums, social networks...).
Starting from now, a new cycle can start. A new development period start from sources of the version.

Then a Dolibarr Yoda add 1 page (one page per version) onto the https://wiki.dolibarr.org to describe content of new version. This is the Release announcement. You can look at the page Category:RoadMap for list of past announcements.

At any time, from the menu System Tools / About Dolibarr / Check integrity, an admin user can check and validate integrity of its installed version compared to official reference. The tool calculate signature of each file and compare it with official signature. All removed and modified files are reported.

Important

At any time, a developer can get all the files of any stable version from Github and using the Tag created at first step of release process.
And at any time, a developer can get all the latest files of a branch (major version including all patches) from Github using the Branch name created at first step of beta process.