Evolución de la plataforma

Los equipos construyen sobre la plataforma. Un cambio que rompe la compatibilidad sin avisar convierte al equipo de plataforma en un riesgo para el resto. Las prácticas básicas son tres: versionar cada cambio, distinguir los compatibles de los incompatibles, y dar un aviso previo y una fecha de retiro razonables a los que rompen compatibilidad.

Un cambio compatible puede entrar con poco aviso; uno incompatible necesita semanas, guía de migración y soporte activo durante la transición.

El orden de trabajo de la plataforma no lo marca quien habla más fuerte ni la última queja, sino la evidencia: cuántos equipos piden lo mismo. Cuando varias peticiones coinciden con los motivos por los que los servicios se quedan fuera del camino, el argumento es todavía más fuerte.

Abre notas/evolucion.txt y evolucion/peticiones-de-equipos.csv.

Una versión retirada ya no recibe correcciones de seguridad. Los servicios que siguen sobre ella quedan con vulnerabilidades conocidas que nadie va a corregir en la plantilla. Se encuentran cruzando el estado de cada versión con el número de servicios que la usan.

Abre evolucion/versiones.csv y evolucion/servicios-por-version.csv.

El calendario de versiones permite ver los problemas antes de que ocurran. Un cambio planificado que rompe la compatibilidad y no tiene días de aviso es una avería esperando fecha: los equipos se enterarán cuando su pipeline falle. Una versión anterior que fue incompatible mostró el modo correcto de hacerlo.

Abre evolucion/versiones.csv.

Con poco personal, la plataforma no puede construir todo. La decisión sana mezcla tres lecturas: lo que piden más equipos, lo que aparece como motivo de salida del camino y lo que reduce un riesgo medido. Una petición que cumple las tres sube al principio; una que solo la pide un equipo ruidoso espera.