Changes

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

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

The most important points we must think about when we decide the frequency of releases are the productivity (the quantity of features) we try to reach and the stability (the quality).

The most important points we must think about when we decide the frequency of releases are the productivity we try to reach (the quantity of features added in a given period) and the stability (the quality).

Let's have a look a this points:

Let's have a look a this points:

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 Requests 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 for enhancements. 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).

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

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: His tasks requires strong technical knowledge, history and anticipatory vision of course, but need a little mobilization compared to the 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/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 ?

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 ?