#1125 closed defect (fixed)
Compatibilidad de un paquete con una versión de TOL
| Reported by: | Víctor de Buen Remiro | Owned by: | Víctor de Buen Remiro |
|---|---|---|---|
| Priority: | highest | Milestone: | TOL Packages |
| Component: | Various | Version: | head |
| Severity: | blocker | Keywords: | |
| Cc: |
Description
Hasta ahora sólo se requería una versión mínima de TOL a partir de la cual un paquete se suponía que iba a funcionar para siempre, es decir, que la compatibilidad hacia atrás se da por hecha.
Sin embargo está claro que ese objetivo no es nada realista, especialmente en el caso de los paquetes que incorporan funciones built-in escritas en C++, ya que en caso de haber una cambio estructural como que se añada o se quite un miembro o una función virtual de cualquiera de las clases manejadas por TOL y usadas en el paquete, se produce una situación de incompatibilidad binaria en ambos sentidos temporales que requiere recompilar el paquete aún cuando no haya cambiado ni una línea de código en el mismo.
Es decir, hay que crear una versión nueva del paquete que será incompatible con la versión vieja de TOL, pero la versión vieja del paquete será también incompatible con la nueva de TOL.
Como ahora mismo el sistema gestor de paquetes lo que hace es traerse el último paquete supuestamente compatible con la versión actual, lo que ocurriría es que los usuarios que no se actualizaran a la nueva versión de TOL se acabarían bajándo paquetes incompatibles que les darían graves problemas que sólo podrían resolver bajando manualmente paquetes que habría que especificarles personalmente.
Se hace necesario un nuevo campo te_max_tol_version en cada paquete que nos diga cual es la versión máxima de TOL compatible con cada él, lo cual es a su vez incompatible con las actuales estructuras TOL TolPackage::@VersionSynchro y TolPackage::@PackageSynchro usadas para la sincronización de paquetes.
En la base de datos sin embargo no hay ningún problema pues la incorporación de nuevos campos no supone ninguna traba importante, salvo que los nuevos campos aparecen al final para no interrumpir el servicio. Como luego las queries pueden establer el orden que se desee esto no tiene ninguna importancia. Mientras el paquete siga siendo compatible con la versión actual de TOL y con los cambios planeados para las siguientes se puede expresar la ausencia de versión máxima estableciéndola como "v999999999999999999".
Aprovechando que se introducen estos cambios se añade otro campo te_extra_info tanto en la base de datos como en las estructuras TOL, en el cual se podrá introducir información extra en un futuro si se hace necesario, sin tener que modificar las estructuras de sincronización. Llegado el caso habría que pensar en como codificar el contenido de dicho campo pero de momento permanecerá vacío por lo que o hace falta perder tiempo en pensar en ello.
Los script PHP que dan acceso remoto a los repositorios deberán ahora distinguir la versión de TolPackage que le está haciendo la consulta para incluir o no los nuevos campos, mediante un argumento añadido tol_package_version que la especifique o por la ausencia del mismo. Para que en un futuro se puedan incorporar otras mejoras de este calibre, el valor de dicho argumento debe ser el de un nuevo miembro TolPackage::_.version
(In [3307]) Fixes #1125
Fixes #1126
Refs #1127
Local repository depends on new member TolPackage::_.version