A current version refactor with significant breaking changes #105
Replies: 3 comments 1 reply
-
If you think old users (v14 to v16) must be clarified, put the full instructions on the readme folder and that's it. |
Beta Was this translation helpful? Give feedback.
-
I’ve come to the conclusion that no matter how much you document changes someone will always be surprised. On that basis if it’s functionally the same, but there’s a risk of data loss and it’s difficult/impossible to create the relevant migrations, I’ve been pushing team members at work to create a new module, effectively leave the old one to die off and leave a big fat warning on the README for the module that it should be considered vestigial (fixes only), not to forward port it to future, and to look at the other module on-going. That way its conscious opt-in choice. |
Beta Was this translation helpful? Give feedback.
-
+1 to new module, letting the other die. |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I have a module I've maintained for many many years. It's current latest version is v14. In the process of migrating to v16, we discovered a different way via an OCA module to achieve the same outcome which is much nicer. Due to some other constraints, primarily _inherit and it's behaviour with many2many fields using relation keyword, I must use the same module name for v14.
It is so different that the diff will be 100%, usage entirely different, views. And the original module will be kept for v14 with the _original suffix.
I am just finishing rewriting it, just doing migration scripts, however do we have a way to significantly warn users who try to upgrade. I know within OCA modules we have had quite a few breaking changes and significant refactors introduced for modules with no warning, so it would be nice to hear peoples ideas on this.
Beta Was this translation helpful? Give feedback.
All reactions