Category:RoadMap

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

Roadmap calendar

Number of releases per year

• Major releases: 2 (This frequency was set and has not been changed since 2011 - See end of chapter about why 2 releases per year)
• Minor maintenance releases: N (depends on bug reports and their criticity)

Dates of releases

YYYY is current year, YYYY+1 is next year

Let's take an example :

Why 2 releases per year ? The limitation of FDKs/Mainteners ?

The most important point we must think about when we decide the frequency of a release are the productivity of features we try to reach and the stability. Let's have a look a this point:

Dolibarr has an integration rate to integrate modifications of code (we call this "Pull Requests" or "PR") of around 95% (Calculation done from PR processed vs PR suggested by developers on GitHub). Hoping to have more merged PRs (so more features), and therefore to have a rate of 98% for example is clearly utopian especially when we know that the merge rate is rather 50% on other projects of equivalent size (example Odoo: 30%, but 85 % for ERPNext, measured in 2022, so after 20 years of existence).

So what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase that is necessary to “digest” a Pull Request for evolution. This time and workload to stabilize integrated developments is exponential with the number of integrated PRs, thus:

• If we release 2 times less often (so 1 every year), the time and efforts to “stabilize” is multiplied by 4 (so slower).
• Seen another way, for an identical result in terms of evolution in the same time, the workload for developers is multiplied by 2 (so less efficient).
• Or again, for an identical result in terms of evolution and an identical workload, the quality of stabilization is divided by 2 if we release 2 times less often (so lower quality).

Today the integration of new PRs is currently deliberately slowed down (this does not prevent Dolibarr from being one of the opensource projects with a highest pace of integrated PR), in order to be able to digest the integrated PRs. Indeed, the bottleneck is mainly in the number of contributors who “correct and stabilize” the integrated PRs. Let's recall the figures, evaluated during a former devcamp: On Dolibarr, for 1 PR of integrated evolution, you need to obtain approximately 2 PR of stabilization fix (2022 evaluation made on Odoo: 2.5, on ERPNext: 7).

However, today the number of enhancement proposed (and which are integrated) is greater than the number of fixes or stabilization (standardization, security, etc.) proposed while it should be 1 PR out of 3 only to be at the balance (3 = 1 for feature + 2 for stabilization). In short, there is no under-staffing on the merge (in fact the workload when you know the app well is quite low) but we frequently have an under-staffing on the Fixers, Debuggers and Killers of Technical Debt that I would call with the initials, the "FDKs" for the following (FDKs are those who work, mainly during a beta phase, to make the application stable and/or coherent, correct regressions, but also during the development phases to reduce technical debt for example). Linus Torvald, from the Linux project, also call them The Maintainers (vs The developers) and said: "We do not have enough maintainers". Dolibarr also miss such contributors on already released versions.

The Merger(s) can be replaced: Its tasks requires strong technical knowledge, history and anticipatory vision of course, but need a little mobilization compared to size of the project (2 half days per week only).

On the other hand, what the project is at risk on is the lack of FDK (because it's an activity which requires a large investment of work, several full time equivalent). This is where the “bus factor” is located on a community project: on the FDKs/Mainteners (I’ll let you see the definition of "Bus Factor" on Wikipedia). The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, to the point of pushing the system into "rolling" release, monthly, or weekly by some. So why not doing the same in Dolibarr to increase the stability and to reduce the workload ?

For Dolibarr, a monthly or even quarterly pace is unfortunately too fast because it is necessary to give the community time to analyze, comment, test and fix on PR (volunteers are working at their own pace, so it needs a more important delay). This is due to the community only mode of the project (which is not necessary in a constrained scheduled project with full employees in a company).

In short, if you have ideas for increasing the number of “FDKs/Mainteners”, or encouraging actors to convert from business developers to FDKs, it is welcome, because this is the bottleneck and where the project is at risk (the problem is that business developer sells their production to customers so we have a large amount of such contributions, but not the FDKs). If we find a “trick” to motivate actors to take on this role in support of the handful of existing FDKs, Dolibarr project will be taken on another dimension…

What about Long Term Support (LTS) version ?

It is common to integrate bug fixes in version develop, stable N, stable N-1, stable N-2 until N-4 (because it makes life easier for the developer to not go back too far), but any bug fix, submitted even in a very old version of Dolibarr (N-x), is integrated (if the PR respects the best practice of the "minimal change for bug fix" of course). So, some people uses to say that every Dolibarr version are LTS. But it is better to say that all versions of Dolibarr are "open to a LTS process". In reality, few developers submit fixes for versions beyond N-5, so very old versions are maintained but only when maintenance contributions are submitted, and because few contributions are submitted for very old versions, we must admit that there is only a "limited" community maintenance support for very old versions.

This is for example a screenshot done when last stable version was v19. It shows the latest recent maintenance fixes done in past versions. Going back 8 major versions in the past (so 4 years ago), we see we still have commits merged in the last month. So we are, naturally, close to LTS at 4 years but far from 6 years LTS (no commits done in the last 2 years for versions N-12 and older when this analysis was done).

In most common cases, this is not a problem because Dolibarr guarantees that you can upgrade to a recent version at any time from any old version (even on a version N-20 released 10 years ago), in few seconds and without loosing data, so you can always benefit of the latest fixes. But if you made some custom modifications in the core or use external modules not yet compatible with recent versions, upgrade may overwrite your custom changes or may make old modules not working anymore. For such cases, you can get contractual support for LTS from some open source companies (Some integrators and some Saas hosting services provide such a support).

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 for the targeted version. It means that we can do some thing, and we can't for some other. This is a 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 (or will be created soon), from develop branch, and called x.y branch. A freeze version is the version we want as the version x.y. Bug fixes start until then version x.y.0 is publicly released. When done, version x.y.* will be maintenance versions (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 and that is not stable. This include changes of code non reachable into the stable version (like experimental code).
  • 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 the rest of the code may be accepted by project merger. 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 hook
    • 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 are forbidden into this branch x.y 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.

Release Process

For information about the release process, see FAQ_Release_process.

List of past versions

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 cumulated ChangeLog file