31,029
edits
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 36: | Line 36: | ||
'''Why 2 releases per year:''' | '''Why 2 releases per year:''' | ||
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 | 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: | Let's have a look a this point: | ||
Dolibarr has | 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 what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase which 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: | So what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase which 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: | ||