id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
1125	Compatibilidad de un paquete con una versión de TOL	Víctor de Buen Remiro	Víctor de Buen Remiro	"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}}}
"	defect	closed	highest	TOL Packages	Various	head	blocker	fixed