From Dolibarr ERP CRM Wiki
Jump to navigation Jump to search

En verysmall.png This page describe what is the Dolibarr release policy and rules. It also includes the list of all past and future releases. For a decription of the process of building a release, see FAQ Release process.

Fr verysmall.png Cette page décrit la politique de release de Dolibarr et présente également a liste des versions futures et à venir.

Es verysmall.png Esta página describe la política de lanzamiento de Dolibarr y también presenta una lista de versiones anteriores y futuras.

De verysmall.png Diese Seite beschreibt die Dolibarr-Freigaberichtlinien / -regeln und enthält am Ende eine Liste aller früheren und zukünftigen Versionen.

Roadmap calendar

Number of releases per year:

  • Major releases: 2 (This frequency was set and has not been changed since 2011)
  • Minor maintenance releases: N (depends on bug reports and their criticity)

Dates are (YYYY is current year, YYYY+1 is next year):

  • January YYYY - Major Release (version A.0.0)
  • April YYYY - Start Major beta (version A+1.0.0): Freeze. Creation of branch A+1.0. See definition of freeze later.
  • June YYYY - Major Release (version A+1.0)
  • November YYYY - Start Major beta (version A+2.0.0): Freeze. Creation of branch A+2.0. See definition of freeze later.
  • January YYYY+1 - Major Release (version A+2.0.0)
  • At any time during year YYYY, maintenance fix releases (version *.*.N) of stable branches (*.*).

Let's take an example :

  • January 2018 - Major Release (version 7.0.0)
  • In march 2018 - Maintenance release 7.0.1 was released
  • 15th of April 2018 - Start Major beta (version 8.0.0): Freeze. Creation of branch 8.0.0
  • In may 2018 - Maintenance release 7.0.2 was released
  • June 2018 - Major Release (version 8.0.0)
  • 15th of November 2018 - Start Major beta (version 9.0.0): Freeze. Creation of branch 9.0.0
  • January 2019 - Major Release (version 9.0.0)
  • etc...

Branch and Source control management

All new features have to be pushed into develop branch. Following the release calendar, branches with name of major version x.y are created by the release manager. According to when we are in the release cycle, those branches can be frozen branches or maintenance branches. See here what this means:

Freeze definition

When we make a freeze of code, it means we start the beta period. It does not means that we must not change the code. It means that we can do some thing, and we can't for some other. This is generic definition of a Freeze.

A freeze is done with a goal of a stable version in mind. To start a freeze, a new branch of sources is created, from develop branch, and called x.y branch. A freeze version is the version into branch x.y until version x.y.0 is publicly released. When done it become a maintenance version (see next definition).

  • When a freeze has started, all following things are still allowed into this branch:
    • Any change of code to fix bugs (code change must however not introduce architecture change nor new library)
    • Any change of code for performance optimizing
    • Any change into translation (language files or adding translation key implementation)
    • Any change into data reference (stored into table llx_c_*. For example, update of vat rates, adding countries, ...)
    • Any change to finish works that was started BEFORE the freeze.
    • Any change into theme or looks (change into HTML to match W3C, or CSS changes).
    • Adding call to dol_syslog().
    • Adding a column into a table (+ upgrade script) or index or constraint, but only if it is required to fix a bug or performance troubles.
  • The following things are not allowed:
    • Any change into architecture.
    • Code standardization nor normalization (except if this is to clean syntax of code).
    • Adding/removing new external libraries.
    • Adding/removing a table, removing a column.
    • Adding new features. However, adding a component whose code is isolated from rest of the code may be accepted by project leader. For example:
      • a "widget file"
      • an "emailing target selector file"
      • a "script" file into /scripts,
      • an utility function
      • a new REST or SOAP API
      • a new export or import profile

Maintenance definition

When a stable version is released, the branch x.y become a maintenance branch. This means, a lot of things can not be done into this branch anymore. This is generic definition of a maintenance branch.

The maintenance branch keep its name x.y, however, each version will be tagged with name x.y.* (* start to 1 and is increased for each new maintenance version). Only changes to fix "blocking", "annoying" or "security" bugs can be done. Bugs making a new feature not available (when feature was never available) must not necessarily be fixed. It 's just a feature not yet ready into this version, it will be available with next major release.

  • The following things are allowed:
    • Any change of code for performance optimizing
    • Change code to fix "blocking", "annoying" or "security".
    • Change for translation (language files only or error of key in code, not changing key into language files).
    • Increasing size of a field.
    • Adding a performance index, only if application can't be used without.
    • Look fixes, only if it affects user readability.
  • The following changes are not allowed:
    • Any change into architecture.
    • Code standardization, including renaming variables, translation keys, mutualizing code.
    • Adding/removing new external libraries.
    • Adding/removing a table, adding/removing/changing a column.
    • Adding a foreign key or unique key.
    • Adding new features, even isolated components or scripts.
  • There is an exception: We can add backported code of version x.y+1 into a maintenance branch to prepare transition for developers of external modules, but only if code added is a complete new method or new function, with no other change.

Note that all branches are always open for contributions to maintenance purpose in GitHub, so if you install Dolibarr using a git clone (recommended installation method for experienced users), you may benefit of a very long term support of your major version, even if no more auto-installer binary packages are generated for this version.

List of past versions

En verysmall.png This Roadmap page is an index of all dedicated pages to RoadMap of each version (past and future). List of each change is available into the ChangeLog file

Fr verysmall.png Cette page Roadmap est un index de toutes les pages RoadMap de chaque version (passée et future).

Es verysmall.png Esta página Roadmap es un índice de todas las páginas dedicadas al RoadMap de cada versión (pasadas y futuras).

De verysmall.png Diese Roadmap-Seite ist ein Index aller dedizierten Seiten zu RoadMap jeder Version (Vergangenheit und Zukunft).