28,967
edits
Changes
m
→Why 2 releases per year
Line 53:
Line 53:
On the other hand, where the project is at risk is the lack of FDK (because it relies on a smaller team and it is 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 FDK (I’ll let you see the definition of Bus Factor on Wikipedia).
On the other hand, where the project is at risk is the lack of FDK (because it relies on a smaller team and it is 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 FDK (I’ll let you see the definition of Bus Factor on Wikipedia).
−The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, 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 stability reducing the workload ?
+The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, 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 (volunteers working at their own pace) time to analyze, comment, test on PR. This is due to the community mode of the project (which is not necessary in a constrained scheduled proprietary projet).
For Dolibarr, a monthly or even quarterly pace is unfortunately too fast because it is necessary to give the community (volunteers working at their own pace) time to analyze, comment, test on PR. This is due to the community mode of the project (which is not necessary in a constrained scheduled proprietary projet).