31,029
edits
Category:RoadMap: Difference between revisions
m
no edit summary
Tag: 2017 source edit |
mNo edit summary Tags: Visual edit Mobile edit Mobile web edit |
||
| Line 9: | Line 9: | ||
==Dates of releases == | ==Dates of releases== | ||
YYYY is current year, YYYY+1 is next year | YYYY is current year, YYYY+1 is next year | ||
| Line 35: | Line 35: | ||
==Why 2 releases per year ? The limitation of FDK ? == | ==Why 2 releases per year ? The limitation of FDK ?== | ||
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. | 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. | ||
| Line 43: | Line 43: | ||
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” 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 that 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: | ||
* If we release 2 times less often (so 1 every year), the time and efforts to “stabilize” is multiplied by 4. | |||
* Seen another way, for an identical result in terms of evolution in the same time, the workload for developers is multiplied by 2. | *If we release 2 times less often (so 1 every year), the time and efforts to “stabilize” is multiplied by 4. | ||
* Or again, to 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. | *Seen another way, for an identical result in terms of evolution in the same time, the workload for developers is multiplied by 2. | ||
*Or again, to 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. | |||
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 only 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). | 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 also call them <nowiki>'''the Mainteners'''</nowiki> | ||
The Merger 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 (2 half days per week only). | The Merger 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 (2 half days per week only). | ||
| Line 117: | Line 119: | ||
== Release Process == | ==Release Process== | ||
For information about the release process, see [[FAQ_Release_process]]. | For information about the release process, see [[FAQ_Release_process]]. | ||
=List of past versions= | =List of past versions= | ||
This Roadmap page is an index of all dedicated pages to RoadMap of each version (past and future). List of each change is available into the cumulated [https://github.com/Dolibarr/dolibarr/blob/develop/ChangeLog ChangeLog file] | This Roadmap page is an index of all dedicated pages to RoadMap of each version (past and future). List of each change is available into the cumulated [https://github.com/Dolibarr/dolibarr/blob/develop/ChangeLog ChangeLog file] | ||