Versiones afectadas y versiones corregidas

Los fabricantes escriben los rangos de varias formas: «2.8.0 a 2.8.1», «hasta la 2.8.1 inclusive», «anteriores a la 2.8.2». Lo que importa es saber si los extremos entran. En un rango escrito «A a B» entran A y B. En «anteriores a C» entra todo lo que sea menor que C, pero no C. Un error de un número en el extremo convierte un activo afectado en uno que parece sano.

Además, casi todo producto se mantiene en ramas paralelas (2.7, 2.8, 3.0): cada rama tiene su propia versión corregida, y subir de rama no siempre es lo que el fabricante recomienda.

Abre la tabla boletin_versiones y después inventario_panel. La primera dice, rama por rama, qué versiones se afectan y en cuál se corrige. Algunas ramas figuran con «sin corrección»: el fabricante ya no las mantiene y no publicará nada para ellas. Un activo en una de esas ramas no se arregla instalando un parche, porque no existe: hay que cambiarlo de rama o compensar.

El inventario dice qué hay; el boletín dice qué rangos fallan. El número de activos afectados es la unión de ambos: se comprueba cada instalación contra el rango de su rama. Una instalación en una rama no afectada, o ya en la versión corregida, no cuenta.

Calcula con los datos de las dos tablas.

La versión corregida de una rama es el destino mínimo para quien se queda en ella. Cambiar de rama puede traer cambios de funcionalidad que exigen pruebas más largas; por eso el aviso da una corregida por rama. Para un activo afectado que sí tiene corrección en su rama, el plan de parche apunta a esa versión concreta.