Contributors mailing list archives
Re: OCA and security noticesby
Tecnativa. S. L., Pedro M. Baeza
The delay depends on 2 factors:
- The technical work to be done, which is the installed core modules to be covered by OpenUpgrade + the OCA modules to be migrated. This can be complemented with use cases test suite to be checked.
- The customer alignment for the best moment to migrate, depending on their activity.
FYI, we are migrating our customers to v13 now, having 4 of them on 13.0 already, and the rest coming in the following months.
El mié, 6 ene 2021 a las 19:07, Xavier Brochard (<firstname.lastname@example.org>) escribió:
Hi Pedro I've found your post very interesting. However can you elaborate a bit on the delay before migration ? Obviously you can't migrate before the newest version is stabilized enough, but you can't also migrate before OpenUpgrade is available (or do you migrate "by hand" ?). So, are you curently running Odoo 13 and planning migrations around june ? Best regards Xavier / zeroheure --- Librement, Xavier Brochard email@example.com La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre Rosnay) Le 05.01.2021 09:27, Pedro M. Baeza (Tecnativa) a écrit : > 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. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:firstname.lastname@example.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe