31,028
edits
Category:RoadMap: Difference between revisions
Jump to navigation
Jump to search
m
→Why 2 releases per year ? The limitation of FDKs/Mainteners ?
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 44: | Line 44: | ||
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 | 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). | ||
| Line 57: | Line 57: | ||
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/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 (remind: making a version stable is exponential to the amount of evolutions of this version) | 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), 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). 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). | ||