Lenguajes: qué versión tienes, hasta cuándo tiene parches y qué cambia

Cómo hacer la lista

Cada lenguaje tiene un comando que dice qué versión está instalada, y muchos proyectos declaran en un archivo cuál necesitan. Con las dos cosas se arma la lista que pide la publicación: qué versión corre en cada sistema y hasta cuándo tiene parches. Las fechas que todavía no llegan son las previstas por cada proyecto y pueden cambiar.

La documentación de Node.js no dice dónde se declara la versión: describe solo los campos de package.json que usa Node, y dice que otros los usan otras herramientas, como npm. Y lo que declara el proyecto no siempre es solo informativo: en Go, si un proyecto (un «módulo») pide una versión más nueva que la instalada, Go la descarga y la usa; si eso está desactivado, se niega a compilarlo.

Python: las fases, el último parche de la 3.10 y la 3.15

Ya publicada, cada versión de Python pasa por tres fases. En la primera («bugfix») acepta correcciones de errores y de seguridad, y publica instaladores nuevos más o menos cada dos meses. A los dos años (antes de la 3.13, a los 18 meses) pasa a «security»: solo correcciones de seguridad, y ya sin instaladores nuevos. A los cinco años llega a su fin («end-of-life»): ya no se acepta ningún cambio. La 3.13 acaba de entrar en «security»: la 3.13.16, del 1 de octubre, fue su última versión con todas las correcciones.

El último parche de la 3.10, la 3.10.22, cerró ocho fallas con identificador CVE (el número con que se registra públicamente cada falla de seguridad). Por ejemplo, una en la que las credenciales que guarda un programa en Python para un sitio HTTPS podían usarse también en su versión HTTP, sin cifrar, y otra al extraer archivos .tar, que podía crear carpetas fuera de la carpeta de destino. Las que se descubran desde ahora ya no se cierran en la 3.10.

Antes de pasar a la 3.15

El cambio que más puede notarse es la codificación, la forma en que se guardan letras como la ñ y los acentos: la 3.15 lee y guarda en UTF-8 los archivos de los programas que no indican la codificación, aunque el sistema use otra. Según el PEP 686, la propuesta oficial que lo definió, afecta sobre todo a quien usa Windows, y en esos programas puede causar errores, texto con caracteres raros o incluso datos dañados sin aviso.

Otros cambios de la 3.15 que pueden romper programas, según su documentación:

• strptime() da error si el formato trae el día (%d) sin el año.
• En sqlite3.connect(), todos los parámetros menos el de la base de datos hay que pasarlos con su nombre.
• Se quitó el modo CGI del servidor web de prueba (python -m http.server --cgi).
• Se quitaron los métodos load_module() de los cargadores de módulos.

Dos novedades son opcionales. La importación diferida carga cada parte del programa hasta que se usa; solo actúa si el código la pide o si se activa con -X lazy_imports=all o con la variable PYTHON_LAZY_IMPORTS=all, y cuando actúa, una parte que falta da el error al usarse, no donde se importa. Y el compilador JIT, que traduce el programa a instrucciones de la máquina mientras corre, sigue siendo experimental: en las pruebas de Python en Linux y en Mac va desde aproximadamente un 15% más lento hasta más del doble de rápido, según el programa.

Un aviso para Windows: el instalador de siempre está en desuso desde la 3.14 y ya no se publicará para la 3.16; lo reemplaza el administrador de instalaciones py.

Node.js: parches el 21 de octubre y un calendario nuevo

En su aviso de parches de octubre, Node.js dijo que el miércoles 21, o poco después, publicará parches de seguridad para la 26, la 24 y la 22; la falla más grave que corrigen es de gravedad alta. El aviso no dice cuántas son, pero sí esto: las versiones que ya llegaron a su fin siempre tienen las fallas que se corrigen. Quien sigue en la 20 o anteriores, o en una impar (21, 23 o 25), las tendrá sin arreglo.

Node.js también tiene fases. «Current» es la versión recién salida, que todavía recibe cambios. «Active LTS», la de soporte a largo plazo, recibe novedades revisadas, correcciones y actualizaciones durante 12 meses. Después pasa a «Maintenance» por 18 meses más: correcciones críticas y de seguridad. Hasta la 26, solo las versiones pares llegan a LTS; las impares dejan de tener soporte a los seis meses. En las próximas dos semanas cambian dos: la 24 pasa a «Maintenance» el 20 de octubre, y la 26 entra a «Active LTS» el 28. La 22 llega a su fin el 30 de abril de 2027.

Desde la 27 cambia el calendario: Node.js sacará una versión al año en lugar de dos, y todas serán de soporte a largo plazo, sin la diferencia entre pares e impares. La 27 empieza en octubre de 2026 como versión de prueba («Alpha»), pasa a «Current» en abril de 2027 y a LTS en octubre de 2027, con soporte hasta abril de 2030. La 26 es la última con el calendario de siempre. Node.js aclara que el plan no es definitivo y puede cambiar.

Para quien no pueda actualizar a tiempo, Node.js dice que hay soporte de pago para las versiones que ya pasaron su fase de «Maintenance», por medio de las empresas socias de su programa «OpenJS Ecosystem Sustainability Program».

La 26, por cierto, trae activada la API Temporal para manejar fechas y horas, y quitó del todo writeHeader() del servidor HTTP: se usa writeHead().

Go: la 1.27

Go da parches a sus dos versiones más nuevas: cuando sale la 1.x+2, la 1.x deja de recibirlos. Con la 1.27, de agosto, la 1.25 se quedó sin ellos; si se sigue el ritmo de siempre, la 1.28 saldrá en febrero de 2027 y la 1.26 dejará de recibir parches.

La 1.27 mantiene la promesa de compatibilidad de Go: casi todos los programas deberían compilar y correr como antes. Lo que puede notarse:

• El paquete encoding/json usa por dentro su nueva implementación. El resultado es el mismo, pero el texto de los mensajes de error puede cambiar; si algo dependía de ese texto, por ahora GOEXPERIMENT=nojsonv2 vuelve a la anterior.
• En Mac pide macOS 13 Ventura o posterior.
• Se quitaron cinco ajustes GODEBUG de TLS y de certificados (como tls3des); si un proyecto los fija en su valor viejo, no compila.
• Ya no funciona con el control de versiones Bazaar (bzr).

Trae además, como opción, firmas poscuánticas, pensadas para resistir a las computadoras cuánticas (ML-DSA, del estándar FIPS 204), y el intercambio de llaves MLKEM1024.

Rust: una versión cada seis semanas

Rust saca una versión estable cada seis semanas, «como un reloj», y solo le da soporte a la más reciente. Si sigue ese ritmo, la 1.100 saldrá hacia el 12 de noviembre y la 1.99 se quedará sin soporte; Rust todavía no anuncia esa fecha. Su documentación insiste en que actualizar a la estable nueva no debería dar miedo.

Entre las notas de compatibilidad de la 1.99, dos que conviene revisar: por omisión, Cargo, la herramienta con la que se compilan los proyectos de Rust, ya no compila de forma incremental (reaprovechando lo ya compilado) cuando detecta que corre en integración continua (CI: el servidor que compila y prueba el código cada vez que alguien lo cambia); y los módulos viejos de números enteros, como std::i32, quedan del todo en desuso (en lugar de std::i32::MAX, se usa i32::MAX). La 1.99.1, del 15 de octubre, corrige errores que se colaron en versiones anteriores, entre ellos uno en el que una función de Rust que devuelve verdadero o falso a código de otro lenguaje, como C, podía entregar un valor mal formado en procesadores x86_64 (los de 64 bits de Intel y AMD); el anuncio no los presenta como fallas de seguridad.

En Cargo.toml, la clave rust-version dice qué versión de Rust necesita el proyecto; si se compila con una que no alcanza, Cargo lo marca como error.

TypeScript 7: lo que deja de aceptar

TypeScript 7 llevó su compilador a Go. En las pruebas de Microsoft compila de 7.7 a 11.9 veces más rápido y usa menos memoria (18% menos en el código de VS Code). Con la opción experimental --checkers 8, que reparte la revisión entre 8 revisores en paralelo (por omisión son 4), el código de VS Code baja de 10.6 a 7.51 segundos, a cambio de usar más memoria. Microsoft aclara que los resultados cambian según el proyecto y la computadora.

Entre lo que la 7 ya da por error:

• compilar a es5;
• baseUrl, y moduleResolution en node o node10;
• los módulos amd, umd, systemjs o none.

Además, hereda los valores por omisión que trajo la 6: el modo estricto (strict) viene activado, y Microsoft avisa que los cambios en rootDir y types son los que más pueden sorprender.

La 7 todavía no trae una API para que otras herramientas la usen; Microsoft espera publicarla con la 7.1. Al 17 de octubre, el blog de TypeScript no había anunciado la 7.1.

Lo que viene en los próximos doce meses

Fuentes

Consultadas del 8 al 17 de octubre de 2026.