Archives
Contributors
Triple discount modules refactor and maturity levels
Hello community
A few months ago, I started a big refactor of triple discount modules in v16.0 that ended up with the following PRs:
Since this is a BIG breaking change I'm wondering if these should be merged only in v17.0 instead of 16.0.
We actually have migration PRs for triple discount modules in 17.0:
My feeling is we must probably leverage the maturity levels to define what can be merged in a released version, and avoid such breaking change when the maturity level is stable/mature. But then, if there is no maturity level in manifest, as is the case here, it seems to default to Beta in readme generation. Should we consider this as a rule?
Do we then want to move forward with this refactor in 16.0 or keep it for 17.0 and eventually define a stable maturity level for 17.0?
Please let me know what do you guys think about it.
Best regards.
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Akim Juillerat
Business solutions Software architect
by Akim Juillerat - 07:06 - 10 Sep 2024
Follow-Ups
-
Re: Triple discount modules refactor and maturity levels
Hi Akim,Thank you for your hard work on the triple discount module. IMO we should merge the 16.0 branch. By bumping the version to the next major level, the signal is clear that this new version contains breaking changes. I'm often reluctant to introduce such deep changes in a ‘stable’ version. In this case, I feel it's justified by the need to introduce a cleaner/simpler approach and remove hacks made necessary by the complexity of the previous one. This cleaner architecture also provides a better basis for all the modules based on this module. Regarding the maturity level, the default one is beta, I would find it logical to prohibit such changes on a ‘stable’/‘mature’ version, but not on a ‘beta’ version.Regards,lmiOn Tue, Sep 10, 2024 at 7:08 PM Akim Juillerat <notifications@odoo-community.org> wrote:Hello communityA few months ago, I started a big refactor of triple discount modules in v16.0 that ended up with the following PRs:Since this is a BIG breaking change I'm wondering if these should be merged only in v17.0 instead of 16.0.We actually have migration PRs for triple discount modules in 17.0:My feeling is we must probably leverage the maturity levels to define what can be merged in a released version, and avoid such breaking change when the maturity level is stable/mature. But then, if there is no maturity level in manifest, as is the case here, it seems to default to Beta in readme generation. Should we consider this as a rule?Do we then want to move forward with this refactor in 16.0 or keep it for 17.0 and eventually define a stable maturity level for 17.0?Please let me know what do you guys think about it.Best regards.camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSAkim JuilleratBusiness solutionsSoftware architect_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Laurent MignonTechnical lead / Management TeamT: +32 2 8883148Atrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumVal Benoit, Quai Banning 6 | B-4000 Liège | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg
by Laurent Mignon - 08:56 - 11 Sep 2024
