La evolución de Tryton ERP se define por una implacable búsqueda de la pureza arquitectónica y la estabilidad, priorizando la calidad del código sobre la complacencia del mercado.

[1.x: Purga Inicial] ──> [2.x: Rigidez PYSON] ──> [3.x: Abstracción Dict] ──> [4.0: CRISIS PYTHON 3 / WSGI] │ (Purga de módulos)
[8.0: REST / Psycopg3] <── [7.x: Mutación JSONB] <── [6.x: Fin Cliente GTK] <── [5.x: Muerte Py2] 

  • Versión 1.x (El Origen): Nacido como un fork ideológico de TinyERP, su propósito fue extirpar el código inestable y las presiones comerciales de su predecesor. La gran mejora fue delegar la seguridad de los datos al motor de base de datos, introduciendo restricciones FOREIGN KEY físicas en PostgreSQL. Esto garantizó una integridad referencial absoluta a nivel de almacenamiento que el ORM original gestionaba de manera blanda.

   Series 1.x (2008–2010) – La Purga de TinyERP: El objetivo único fue extirpar el código inestable heredado. Se introdujeron restricciones FOREIGN KEY reales en PostgreSQL, obligando a la base de datos a auditar la integridad. Las migraciones eran artesanales; los integradores pasaban semanas ejecutando sentencias ALTER TABLE manuales debido a la falta de herramientas de automatización en el instalador básico.

  • Versión 2.0 (Consolidación de PYSON): Para resolver los riesgos de seguridad derivados de ejecutar código imperativo directo del servidor en el cliente, se introdujo PYSON. Al empaquetar sentencias lógicas en un formato declarativo seguro (similar a JSON), se evitó la inyección de código y se permitió que cualquier interfaz evaluara reglas dinámicas sin necesidad de acceder directamente a la base de datos.

Series 2.x (2011–2012) – La Consolidación de PYSON: Se introdujo PYSON (Python Statement Object Notation), un DSL (lenguaje específico de dominio) interno para enviar lógica condicional ejecutable al cliente sin evaluar código Python directo. Esto rigidizó el desarrollo: los módulos custom mal diseñados que dependían de la ejecución dinámica en el lado del cliente se rompieron por completo.

  • Versión 3.0 (Desacoplamiento Tabular – Campos Dict): Añadir atributos dinámicos a los productos tradicionalmente implicaba colapsar el motor con instrucciones ALTER TABLE o sufrir la extrema lentitud de consultas del modelo EAV. La incorporación de los campos Dict permitió almacenar infinitos atributos clave-valor en una única columna estructurada, ofreciendo flexibilidad total sin bloquear las tablas físicas de PostgreSQL.

Series 3.x (2013–2015) – Desacoplamiento Tabular: La introducción de los campos Dict (Diccionarios) permitió añadir atributos dinámicos a los modelos sin mutar la estructura física de PostgreSQL. Fue un avance, pero fragmentó el ecosistema: muchos módulos comunitarios que dependían de la creación masiva de columnas reales en las tablas quedaron obsoletos por ineficiencia de almacenamiento.

  • Versión 4.0 (El Rompeaguas / La Gran Crisis): El punto de inflexión más traumático del proyecto. Tryton forzó la migración estricta a Python 3, provocando fallos masivos en la gestión de strings y datos binarios (bytes) en módulos personalizados. En paralelo, se sustituyó el protocolo Net-RPC propietario por el estándar WSGI vía Werkzeug. Esta transformación hacia una arquitectura Stateless (sin estado) decretó la muerte de las conexiones TCP persistentes. Los módulos comunitarios que no se reescribieron para estas nuevas APIs fueron eliminados del repositorio oficial sin contemplaciones, obligando a muchas empresas a realizar reimplantaciones completas.

El Agujero Negro de Tryton: La Crisis de la Serie 4.0 (2016)

La versión 4.0 representó la mayor crisis de migración y la brecha más profunda entre el núcleo de desarrollo y la comunidad de integradores. El Core Team tomó dos decisiones simultáneas de un impacto técnico masivo: la migración total a Python 3 y el reemplazo del servidor de red por el estándar WSGI.

2.1 El Desafío del Intérprete (Python 2.7 $\rightarrow$ Python 3)

En 2016, la mayor parte del ecosistema de librerías empresariales seguía anclado en Python 2.7. Tryton decidió forzar la compatibilidad con Python 3 de manera estricta. Esto significó que:

  • Tratamiento de Cadenas (str vs bytes): Python 3 cambió radicalmente cómo se gestionan los strings (ahora Unicode por defecto) y los datos binarios. Todo el código del ORM y de los módulos que manipulaba archivos adjuntos, reportes PDF, facturas electrónicas o comunicaciones de red falló con excepciones de codificación (TypeError).

  • Librerías de Terceros Huérfanas: Módulos críticos para la industria (conectores fiscales, pasarelas de pago locales, librerías de generación de códigos de barras) no estaban adaptados a Python 3 en 2016. Los integradores se encontraron con un ERP moderno pero incapaz de conectarse con los servicios locales de sus países.

2.2 Revolución en la Capa de Red: Adopción de WSGI

Hasta la versión 3.8, trytond gestionaba sus conexiones mediante servidores de sockets personalizados (basados en herencia directa de protocolos Net-RPC y XML-RPC rudimentarios). En la 4.0, se eliminó por completo este motor interno y se adoptó WSGI de forma nativa a través de la librería Werkzeug.

Esto cambió la forma en que el ERP respiraba:

  • Desaparición de Net-RPC: El protocolo binario rápido y propietario de Tryton fue suprimido. El cliente de escritorio (GTK) fue obligado a comunicarse exclusivamente a través de HTTP/HTTPS mediante JSON-RPC.

  • Muerte de las Conexiones Persistentes: Los módulos que dependían de mantener hilos de ejecución abiertos por cada usuario para realizar tareas en tiempo real (como la escucha de periféricos de almacén o básculas de pesaje) colapsaron. El nuevo modelo era estrictamente Stateless (sin estado), gobernado por transiciones HTTP limpias.

2.3 La Purga: Eliminación Masiva de Módulos

El impacto más severo de la 4.0 fue la extinción de módulos por falta de reconversión. El equipo central de Tryton aplica una política implícita: si un módulo del repositorio oficial no es adaptado a las nuevas APIs y probado bajo el nuevo entorno de tests automáticos antes del congelamiento de la versión (code freeze), el módulo se elimina de la distribución oficial.

Múltiples componentes sectoriales y herramientas avanzadas sufrieron este destino:

  1. Módulos de Gestión de Proyectos Avanzados y Extensiones de Tiempos: Al cambiar el modelo de bloqueo de transacciones (Two-Phase Commit o 2PC en la 4.0) para soportar bases de datos distribuidas, la lógica concurrente de estos módulos provocaba deadlocks (bloqueos mutuos) continuos en PostgreSQL. Al no haber desarrolladores dispuestos a refactorizar la lógica de hilos, se retiraron del core.

  2. Módulos de Integración con Terceros (E-commerce y CRM antiguos): Las herencias declarativas cambiaron su firma de métodos internos en el ORM (por ejemplo, mutaciones severas en ModelView y la gestión de llamadas del sistema de permisos ir.model.access). Los conectores comunitarios simplemente dejaron de cargar, provocando que el servidor se apagara en el arranque si intentaban usarse.

El Coste para las Empresas: Para los clientes que operaban en la serie 3.8 con un alto grado de personalización, actualizar a la 4.0 no fue una migración; fue una reimplantación total. Muchas empresas decidieron congelar sus sistemas en la versión 3.8 durante años, rompiendo el ciclo de vida de soporte y aumentando el riesgo de seguridad por obsolescencia.

  • Serie 5.0 (Gestión Asíncrona con Workers): La arquitectura Stateless de la 4.0 destapó un problema: las tareas pesadas (como grandes reportes contables) bloqueaban los hilos HTTP del servidor web, provocando caídas por timeout. La solución en la 5.0 fue el rediseño de colas asíncronas delegadas a workers independientes de fondo. El servidor web quedó libre para atender transacciones rápidas, mientras los procesos pesados se calculaban en paralelo.

Serie 5.0 (2018) – El Fin del Soporte Dual: Se eliminó definitivamente cualquier rastro de compatibilidad hacia atrás con Python 2.7 (la versión 4.x aún permitía cierta ejecución híbrida). Se rediseñaron las colas de tareas asíncronas con workers independientes para evitar que los reportes pesados colgaran las peticiones HTTP del servidor WSGI introducido en la 4.0.

  • Serie 6.0 (La Eutanasia del Cliente GTK): Mantener el cliente de escritorio local exigía al departamento de TI lidiar con librerías dinámicas (.dll) y actualizar cada terminal en cada cambio de versión. La depreciación final de GTK en favor del cliente web adaptativo (tryton-js) redujo el coste de despliegue a cero, permitiendo el acceso multiplataforma desde cualquier navegador moderno.

Serie 6.0 (2021) – La Eutanasia del Cliente GTK: El cliente de escritorio nativo (GTK), que había acompañado a Tryton desde sus orígenes, comenzó su depreciación final en favor del cliente web (tryton-js). Esto obligó a una reescritura masiva de la capa de presentación: las interfaces construidas con layouts XML complejos que se renderizaban bien en pantallas de escritorio fallaban o se desalineaban por completo en el navegador web.

  • Serie 7.x (La Mutación JSONB): Diseñada como una transición escalonada y fragmentada hacia la siguiente generación, su mayor hito fue reemplazar las tablas intermedias de relaciones multiselección por el tipo de datos JSONB nativo en PostgreSQL. Indexadas mediante índices GIN, estas columnas eliminaron los costosos JOINs en disco, acelerando de forma exponencial las búsquedas masivas.

Serie 7.x (2023–2025) – La Ruta de la Mutación Silenciosa: Como se mencionó en el análisis anterior, la serie 7.x dividió el impacto arquitectónico de la futura versión 8.0 en pasos semestrales. La migración de campos multiselección a estructuras JSONB nativas en la 7.4 obligó a limpiar bases de datos vivas mediante scripts de SQL manuales para corregir discrepancias en la tabla de metadatos ir_model_data.

  • Serie 8.0 (Madurez Headless y Psycopg3): La consagración de la arquitectura moderna. Se introdujo una API REST oficial estandarizada que permite integraciones directas con plataformas externas (como Shopify o apps móviles) sin descifrar el RPC interno. Además, la adopción del driver Psycopg3 habilitó la asincronía y el Pipelining SQL, permitiendo enviar ráfagas de consultas simultáneas para pulverizar el impacto de la latencia de red en entornos en la nube (Cloud-native).

Serie 8.0 (2025–2026) – La Madurez Headless y Psycopg3: Con la llegada de la versión 8.0, Tryton cosecha los frutos del sufrimiento de la 4.0. Al estar completamente montado sobre WSGI y con una API REST estandarizada de forma nativa, el ERP se transforma en una plataforma preparada para la nube (cloud-native). La adopción de Psycopg3 le permite hacer pipelining de consultas, optimizando drásticamente los flujos de datos que en la era de la 4.0 saturaban el servidor HTTP.

Conclusión Técnico-Histórica

La crisis de la versión 4.0 demostró la cara más dura del modelo de gobernanza de Tryton: la estabilidad del núcleo técnico está por encima de la comodidad del mercado. Mientras competidores como Odoo mantuvieron deuda técnica durante años en su transición a Python 3 para no alienar a sus partners comerciales (generando un ecosistema fragmentado y con parches de compatibilidad ineficientes), Tryton prefirió amputar módulos completos y asumir la pérdida de adopción masiva con tal de mantener un código fuente predecible, elegante y matemáticamente consistente.

Para un arquitecto de sistemas, la lección de Tryton es clara: es un ERP diseñado para ingenieros. Las migraciones entre series mayores exigen un control absoluto de la base de datos y del código de los módulos involucrados; no existen los milagros automáticos en sistemas que priorizan la integridad contable absoluta.

Realizado por Telepieza, ChatGPT y GEMINI.