Chaque automne, Odoo annonce une nouvelle version. Et chaque automne, la même question revient : est-ce que je dois migrer, et qu'est-ce que ça va me coûter ?
La liste des nouveautés ne répond pas à cette question. Elle dit ce qu'Odoo vend. Elle ne dit pas ce qui casse chez vous.
Voici comment obtenir la seconde liste, celle qui compte.
Les release notes disent ce qui est ajouté, pas ce qui est déplacé
Une page de release notes annonce des fonctionnalités : un nouveau module, une vue repensée, un moteur de recherche plus rapide. C'est de la communication produit, et c'est utile pour décider si une version vous apporte quelque chose.
Ce qui vous coûte du temps est ailleurs. Un champ renommé, un modèle fusionné, une méthode qui disparaît, une vue standard dont la structure XML a bougé : rien de tout cela n'apparaît dans les release notes, et c'est pourtant ce qui casse vos modules personnalisés.
Vous avez donc deux listes à lire, pas une.
Où lire ce qui change vraiment
Le Coverage Analysis d'OpenUpgrade liste, pour chaque version, les modules ajoutés, les modules supprimés et l'état des scripts de migration module par module. C'est la vue d'ensemble.
Les fichiers d'analyse d'openupgrade_scripts donnent le détail. Dans le dépôt OpenUpgrade, chaque module porte un fichier d'analyse par palier de version, qui énumère les champs ajoutés, renommés, supprimés, et les modèles concernés. Si votre module hérite d'un modèle standard, c'est là que vous voyez ce qui vous attend.
Le wiki maintainer-tools de l'OCA liste les changements à appliquer dans votre code, module par module, pour passer d'une version à la suivante.
Le dépôt d'Odoo lui-même. Un git diff entre les deux branches, limité aux modules dont vous héritez, est la source la plus honnête qui existe. Plus long à lire, jamais faux.
Les trois postes qui cassent
Sur les migrations que j'ai faites depuis 2016, la casse arrive presque toujours dans cet ordre.
- Les vues. Votre XPath cible une structure que la nouvelle version a déplacée ou renommée. Le module ne s'installe plus.
- Les champs calculés. La dépendance sur laquelle ils reposent a changé de nom, de type ou de comportement. Le module s'installe, et le calcul devient faux en silence. C'est le poste le plus dangereux.
- Les workflows métier. Odoo ajoute au standard une fonctionnalité que votre module faisait à la main. Rien ne casse techniquement, mais vous maintenez désormais du code en double.
Ce que vous faites de cette liste
Vous la traduisez en décision, module par module. Trois issues seulement :
- Le standard fait maintenant le travail : vous supprimez votre module et vous reprenez les données dans le modèle standard.
- Le module reste utile : vous adaptez le code et vous écrivez le script de migration des données.
- Le module ne sert plus : vous le désinstallez proprement avant la migration, pas après.
Une migration réussie retire du code personnalisé. Si la vôtre n'en retire jamais, votre instance s'éloigne du standard à chaque version, et chaque migration coûte plus cher que la précédente.
Le réflexe à prendre dès le jour 1
Vous n'avez pas besoin d'attendre une migration pour lire ces listes. Le jour où une version sort, ouvrez le Coverage Analysis et regardez les modèles dont vos modules héritent. Vous saurez en une heure si la version suivante sera calme ou chaotique, et vous pourrez arbitrer sur du concret.
Ensuite, quand vous décidez de migrer : le guide complet de la migration Odoo avec OpenUpgrade donne l'ordre à respecter, la commande exacte et les pièges.