Changes

m
Line 43: Line 43:  
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).