Changes

Dolibarr has an integration rate to merge 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 between 30% and 85% on other projects of equivalent size (Odoo: 30%, ERPNext 85%, measured in 2022, so after 20 years of existence).

Dolibarr has an integration rate to merge 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 between 30% and 85% on other projects of equivalent size (Odoo: 30%, ERPNext 85%, 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” the Pull Requestws of evolution. We must know that the time and workload to stabilize integrated developments is exponential with the number of integrated PRs, thus:

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” the Pull Requests of evolution. We must know that the 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 major version every year), the time and efforts to “stabilize” is multiplied by 4 (so releasing is harder).

*If we release 2 times less often (so 1 major version every year), the time and efforts to “stabilize” is multiplied by 4 (so releasing is harder).

*Seen another way, for an identical result in terms of evolution/geature in the same time, the workload for developers is multiplied by 2 (so less efficient).

*Seen another way, for an identical result in terms of evolution/feature 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).

*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).

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).

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, 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 "'''FDK'''s" 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 old released versions (when we have too much on develop version).

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 "'''FDK'''s" for the following (FDKs are those who work, mainly during a beta phase, to make the application stable and/or coherent, who correct regressions, but also during the development phases who work 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 old released versions (when we have too much on develop version).

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 (i.e: load in 2024 is 2 half days per week only).

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 (i.e: load in 2024 is 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 (remind: making a version stable is exponential to the amount of evolutions 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 ?

On the other hand, what the project is at risk on is the lack of FDK/Maintener (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 is the solution taken by many projects to make stabilization easier (remind: making a version stable is exponential to the amount of evolutions of this version, so releasing often means easier to stabilize), 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 (when introducing such delays is not necessary in a constrained scheduled project with full employees in same company).

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 for discussion, coordination, validation). This is due to the '''community only''' mode of the project (when introducing such delays is not necessary in a constrained scheduled project with full employees in same company).

In short, if you have ideas for increasing the number of “FDKs/Mainteners”, or encouraging actors to convert from feature developers to FDKs, it is welcome, because this is the bottleneck and where the project is at risk (the problem is that feature developers sell their production to customers so we have a large amount of such contributions, but not the FDKs when you have a mature solution like Dolibarr). 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…

In short, if you have ideas for increasing the number of “FDKs/Mainteners”, or encouraging actors to convert from feature developers to FDKs, it is welcome, because this is the bottleneck and where the project is at risk (the problem is that feature developers sell their production to customers so we have a large amount of such contributions, but not the FDKs when you have a mature solution like Dolibarr). 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…

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.

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 past 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 the major versions N-12 and olders when this analysis was done).

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 past month for all of them. 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 the major versions N-12 and olders when this analysis was done).

<div class="divforimgcentpercentx">

<div class="divforimgcentpercentx">

=Branch and Source control management=

=Branch and Source control management=

All new features have to be pushed into '''develop''' branch.

All new features have to be pushed into '''develop''' branch. Bug fixes are into '''version branches''' (trying to follow this [[Decision algorithm for branch choice of a PR]]).

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:

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:

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.

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==

==Release Process==