No hay formas correctas de programar o de mantener cada módulo que creamos de Odoo; sin embargo podemos decir que existen convenciones más aceptadas que otras. Si nos interesa que nuestro módulo sea público para que otro desarrollador lo utilice y eventualmente colabore, es importante ser consistentes y mantener un orden. También es clave para el mantenimiento interno de nuestros módulos, es muy probable que pasados unos meses nos olvidemos para que versión de Odoo armamos el módulo, si tiene cosas a tener en cuenta al momento de instalar, si depende de otro módulo, etc. Por eso me pareció interesante compartir un poco la guía que me suelo imponer en los módulos que armo tanto a nivel personal como en equipo de trabajo, siguiendo tanto la convención de Git (de la que ya hablamos en este blog) como una mezcla de convenciones de repositorios de Odoo y OCA.
Versión de Odoo y las Branches
Uno de los dolores de cabeza más comunes al mantener módulos para distintas versiones de Odoo es la versión anual, y eso lleva a que exista una forma de identificarla en el repositorio. Quiero decir, no tiene sentido tener un repo por módulo y por versión. Para eso hay algo no escrito, heredado del repositorio oficial de Odoo, y es el uso de las Branches. Una Branch de Git por versión de Odoo, respetando la numeración (11.0, 12.0, 13.0, 14.0, etc). Eso hace que sea muy sencillo no solo su mantenimiento sino su implementación, simplemente hay que clonarse la Branch de la versión. No obstante, las Branches de Git tienen otro uso, para el desarrollo de versiones justamente. En estos casos se recomienda seguir utilizando Branch de Dev y Master en paquetes grandes. La Branch Master se emplea para probar la última versión antes de pasarla a su correspondiente número de versión, siempre que el código termine en una Branch con número de versión se considera que el código puede usarse en producción.
El Archivo README.md
Una cosa interesante de los servicios online de Git (GitHub, Bitbucket, GitLab) es que renderizan en la propia página del repositorio lo que pongamos en el archivo README.md utilizando texto enriquecido con MarkDown. Esto puede ser muy aprovechado, y debería serlo, en los repositorios de módulos de Odoo para dar una explicación de lo que hace dicho módulo (no siempre el nombre del mismo se entiende). Además, si el repositorio es un paquete de módulos, se puede dar una breve descripción de cada uno a modo de "home" y luego la detallada dentro del módulo (como hace OCA). También se puede utilizar para explicar consideraciones de instalación, configuración, funcionamiento e incluir autores.
Dependencias
Si nuestro módulo tuviese dependencias, habrá que incluirlas de alguna manera también. Las dependencias de Python pueden ponerse en un archivo requeriments.txt como indica la convención, ya que permite automatizar la instalación de las mismas. Si tuviese dependencias de OCA, se suele utilizar un archivo oca_dependencies.txt donde se coloque la URL del Git remoto. Si hubiese otras dependencias, seguimos la misma lógica en otro archivo TXT, puede llamarse other_dependencies.txt o simplemente dependencies.txt.
