Vamos a volver a desmontar 2 mitos muy extendidos:

1. Las versiones pares no son más estables.

El que durante una o 2 versiones muy en el pasado Odoo no andara muy fino justo en la salida de ciertas versiones impares (básicamente, 9 y 11), no significa que eso hoy día siga igual. Se suelen hablar de dos cuestiones: la propia estabilidad del código, y los cambios mayores en estructuras de datos o framework.

Sobre la estabilidad del código, Odoo ha mejorado mucho en cobertura de tests y procesos internos para entregar de salida una versión mucho más estable. Está claro que cada versión recién salida, incluye un número de bugs o de flecos que se van puliendo por parte del propio Odoo o de la comunidad durante el ciclo de vida de dicha versión, pero en general usar una nueva versión al poco de haber salido se hace una experiencia más agradable ahora, y también muchos de los parches propuestos tienen que ver con casos de uso específicos.

Como ejemplo de paridad, Tecnativa ha hecho el mismo número de propuestas de parche a Odoo en la versión 15 (13):

https://github.com/odoo/odoo/pulls?q=is%3Apr+is%3Aopen+involves%3Atecnativa+15.0+

que a la versión 16:

https://github.com/odoo/odoo/pulls?q=is%3Apr+is%3Aopen+involves%3Atecnativa+16.0+

(aunque estos números pueden cambiar cuando se visiten estas direcciones en el futuro, pero incluso en detrimento de la versión 16).

Sobre los cambios mayores en estructura de datos o framework, igualmente el que haya existido alguna versión en la que parece haber habido menos cambios de estructuras es pura casualidad. La realidad es que Odoo mete el cambio cuando le conviene según su ciclo de desarrollo, sin importar si la versión que toca es par o impar. Un par de ejemplos de esto pueden ser el cambio del cliente web al framework OWL en la versión 16 (par) o el cambio de la tabla ir_translation a campos JSON para los campos traducibles también en esta misma versión 16.

2. La localización en la versión X no está completa.

El repositorio OCA/l10n-spain almacena muchísimos módulos que están relacionados con la localización, pero para tener el Odoo de un cliente localizado, no se necesitan todos, ya que muchos de ellos responden a casuísticas fiscales específicas, o son características que incluso la empresa usuario de Odoo no necesita según sus necesidades. Ejemplo: los módulos l10n_es_atc_* solo los necesitarás si tu compañía tiene sede o almacén en Canarias, y además se encarga la propia compañía de declarar los impuestos. Lo mismo para los l10n_es_aeat_*. Muchas compañías tienen externalizada la fiscalidad y no necesitan nada de todo esto.

También el número de módulos puede variar de una versión a otra dependiendo de las vicisitudes de la misma. Por ejemplo: los módulos l10n_es_*_extra_data se han creado en versiones anteriores a las soportadas oficialmente por Odoo para albergar los nuevos impuestos, pero en las últimas versiones no son necesarios porque esos impuestos ya van incluidos en l10n_es core, y en los módulos padre de l10n-spain.

Por ello, el termómetro de completitud de la localización en una versión no es decir que en la versión anterior había 60 módulos, y en esta versión solo se ven 30, por lo que la localización está al 50%. Para muchas empresas, esos 30 módulos son más que suficientes, y para otras con casuísticas fiscales especiales no les valdrá ni la versión anterior, ni la actual, porque no esté cubierto o migrado. Para cada implantación de Odoo, hay que conocer sus necesidades a nivel de localización y ver si están cubiertas en alguna versión, y sobre ello, decidir:

• Si quedarse en una versión anterior porque esas casuísticas están contempladas en esa versión, pero perdiendo todas las novedades del propio Odoo de la nueva versión.
• Migrar los módulos que cubren esas casuísticas a la versión interesada. No entiendo por qué muchas empresas que pretenden ganar dinero con Odoo son simples actores pasivos de esto, y esperan a que otros migren los módulos que necesitan (bien sean de la localización u otros OCA), y mientras tanto se quedan en versiones anteriores, entregando a sus clientes versiones peores. Migrar módulos en muchos casos puede ser muy sencillo, y es ponerse a ello si se tiene personal desarrollador. Y si no, financiar a los que han contribuido esos módulos para que los migren. Igual que se hacen otro tipo de inversiones (de personal comercial, a la agencia de marketing correspondiente, el partnership de Odoo, etc), es loable y recomendable invertir en externalizar algunos de estos trabajos para poder ofrecer la nueva versión según proyectos. Así también puede servir como agradecimiento y retribución a las empresas que han contribuido en el pasado con esos módulos o migraciones, y no solo actuar en modo leecher.
• Si no existe la funcionalidad aún en ninguna versión, plantearse desarrollarla para pasar a tener la misma en Odoo. Cada característica y funcionalidad extra, en algún momento no ha existido en Odoo, y alguien (vía financiación del cliente o I+D propio), la ha aportado para pasar a existir. Igualmente, conviene ser proactivos en esta cuestión para seguir expandiendo más y más el alcance funcional del sistema.

Entonces, en mi opinión, limitarse como implantador a solo versiones pares (o para el caso, a impares), es perder muchas oportunidades, ya que puede haber módulos que estén en una versión que no sea la que te corresponde, entregar al cliente un producto de menor calidad, ya que esa versión que se entrega es normalmente más antigua que la que podría ponerse en un momento dado. Ejemplo: los que siguen las versiones pares, aún a fecha de hoy, 2 años más tarde, tienen que implantar la mayoría de veces la versión 16, ya que la versión 18 está iniciando su recorrido, cuando podrían poner la versión 17 desde hace un año.

También la adaptación del personal a los cambios sufridos durante dos versiones en mi experiencia lo considero peor que ir gradualmente adaptándose versión a versión.

Dos ramificaciones de esto es quedarse estancado en una versión en concreto, o no migrar a los clientes de versión, que son otros enfoques que algunos implantadores han tomado como intento de ahorrar costes. Esto, siempre bajo mi opinión, tendría los mismos problemas ya comentados de obsolescencia y producto de menor calidad, y además produciría un sobrecoste para llevar a esas versiones los cambios legislativos (por ejemplo, los últimos cambios del IVA de alimentos o el futuro Veri*factu), diluyendo parte de esos ahorros. La mejor manera de poder amortizar los costes de migración de cada cliente que pueden suponer es acordar con el cliente un prorrateo de los mismos (vía un contrato de mantenimiento), para quitar de la ecuación eso de "¿qué trae la nueva versión para que me merezca la pena pagar X?".

Bonus: ¿Por qué a fecha de hoy, no ha habido apenas actividad en la rama 18.0 de OCA/l10n-spain? Precisamente porque los que contribuimos normalmente en OCA no tenemos la necesidad de ir desde el día 0 a la 18, como sí que tienen más los que se han saltado la 17. Igualmente, por la forma de trabajar de ir migrando a los clientes de versión, si ahora no entran a la 18, ya entrarán dentro de poco (o a la 19, ya que no es obligatorio migrar a todos cada versión, y es algo que se suele acordar con el propio cliente).

Totalmente de acuerdo con Enric