Hi, Tom,
Each version can have some bugs, but it's better to handle them between more people than let SaaS users or the same partners to notify/fix them. You think it's "safer" to be on a previous version for avoiding such bugs, but the facts are:
- Such a bug is because of your use cases, and it will be found on the version you are using, no matter if outdated or not. Nobody till then may notify it.
- Odoo is fixing bugs very quickly and without effort by your part on the latest version (or the previous one), as they are committed to "stabilize" that version, but not on very old versions. A note about this: notifying properly a bug is the key for having it solved. You can't expect to have the work done not doing a minimum effort on your part.
- Bugs can happen even on unsupported versions, so the maintenance cost starts to rise if you need to fix them by yourself and you are introducing regression risks.
- There are even occasions where the bug is fixed or doesn't apply on higher versions, but you don't have it in an outdated one. See the recent CVE cases and the effort needed by Stefan and Nils.
- Odoo continues to improve its test suite, and each version has more and more stability/quality.
Other facts about using outdated versions:
- You need to "backport" features that are on higher versions or lack them.
- Framework evolves, and using an outdated framework makes your development team to require more time to complete the same tasks, or to not have available some tools. Programming in 2020 with the old API or the v8/v9 hybrid for me is horrible.
- Collaboration possibilities are reduced working on an outdated version, as there are less contributors on them. You can see the same examples on your 7.0 PRs, or even on the 10.0 PRs, that is more recent, but the same unattended.
- As a complement to the previous one, new contributors push newer versions, not old ones.
- Underlying libraries and dependencies are outdated as well, with the problems this supposes.
So at Tecnativa we deal with this not having middle positions: all our customers go to latest versions (the supported ones), and we reject those that don't want this approach. That way, we focus on dealing with a reduced set of Odoo versions, we migrate them regularly (not forcing a yearly migration, but more and more customers demand to go to each version and they don't want to keep the same version 2/3 years), and we report bugs to Odoo constantly that makes the versions stable enough.
Migrating OCA modules is not a problem while you are on the wheel. The keys are:
- Having a team used to OCA guidelines. All our developments follow strict guidelines. This makes the team to take the habit and don't require more time to be "OCA". Anyway, 95% of our developments are directly OCA. OCA first approach is also very important for us.
- Having good test coverage. This is vital for easing the migrations. Doing good tests is not easy, but the time spent on that will be for sure gained later. This includes also JS tour/Qunit tests if needed.
- Reviewing PRs between colleagues as part of your development cycle. This raises a lot your team skills and don't stuck PRs. People complain about their PRs not being reviewed, but they don't review others in exchange or don't push colleagues to review them.
We also take a proactive position for handling some "polemical" decisions taken on the versions, creating OCA modules that fill the gaps. This is better IMO than staying on an older version and complaining that "Odoo has removed this or changed that". In general you win more than you lose on newer versions.
And finally, customers receive a refresh training on each version change. Being proactive as well on the changes they have makes people to not reject the new version and embrace the new features from the beginning.
Do I convince you, hehe?
Regards.
Re: OCA and security notices
OCA and security notices
