Rust llega a la versión 1.100 con dos cambios largamente esperados
El equipo de lanzamientos de Rust publicó el 12 de noviembre de 2026 la versión 1.100.0 del lenguaje, una entrega que, más allá del simbolismo de alcanzar las tres cifras, resuelve dos asuntos que la comunidad arrastraba desde hace años. Por un lado, se estabiliza el tipo never, el tipo que representa las expresiones que nunca producen un valor y que se escribe con el signo de exclamación. Su llegada al canal estable culmina un proceso de alrededor de diez años marcado por cinco intentos fallidos de estabilización. Por otro lado, Cargo, el gestor de paquetes y sistema de compilación del lenguaje, incorpora la edad mínima de publicación de dependencias, una función conocida en inglés como dependency cooldowns y descrita en el RFC 3923, que permite ignorar versiones de crates publicadas hace menos de un plazo configurable.
Ambas novedades responden a motivaciones distintas. La primera es una cuestión de diseño del sistema de tipos que afecta a la expresividad del lenguaje y a la coherencia entre ediciones. La segunda es una respuesta práctica al aumento de los ataques que aprovechan los registros públicos de paquetes para distribuir código malicioso. A ellas se suma la estabilización de la API de asignadores de memoria, una pieza que los desarrolladores de sistemas de bajo nivel llevaban tiempo reclamando, además de un puñado de funciones nuevas en la biblioteca estándar y mejoras en la forma en que Cargo detecta dependencias que no se usan.
La versión llega, como es habitual en el proyecto, a través del ciclo de publicaciones cada seis semanas, y puede instalarse con la herramienta rustup por quienes ya tienen una versión anterior del compilador. Sin embargo, a diferencia de muchas entregas recientes, esta incluye un cambio de comportamiento que el propio proyecto señala como posible fuente de roturas en código existente, lo que obliga a los equipos a revisar con algo más de cuidado su proceso de actualización.
Qué es el tipo never y por qué importa
En Rust, toda expresión tiene un tipo. Una suma de enteros produce un entero, una llamada a una función que devuelve una cadena produce una cadena. Pero hay expresiones que no producen ningún valor porque la ejecución nunca continúa después de ellas: una llamada a panic, una instrucción return dentro de una función, un break o un continue dentro de un bucle, o una función que entra en un bucle infinito. Estas expresiones se denominan divergentes, y su tipo es precisamente el tipo never.
La particularidad del tipo never es que no tiene ningún valor posible. Eso, que a primera vista parece una curiosidad teórica, tiene consecuencias muy prácticas. Como una expresión de tipo never nunca llega a producir un resultado, el compilador puede tratarla como compatible con cualquier otro tipo. Es lo que permite, por ejemplo, que en una expresión match una rama devuelva un número y otra rama invoque panic sin que el compilador proteste por la diferencia de tipos.
Hasta ahora, esa capacidad existía de forma parcial. Los programadores podían declarar que una función devolvía el tipo never, pero no podían usarlo libremente en otras posiciones. Con la estabilización en Rust 1.100, el tipo puede nombrarse en cualquier lugar donde se admita un tipo, por ejemplo como parámetro de un genérico. El caso más citado es el de un resultado que nunca puede fallar: un Result cuyo tipo de error sea never expresa, directamente en el sistema de tipos, que esa operación es infalible.
Para esa situación, la biblioteca estándar ofrecía desde hace años un sustituto: el tipo Infallible, una enumeración sin variantes que cumple un papel parecido. Según el anuncio del proyecto, en esta versión Infallible pasa a ser un alias del tipo never, de modo que las API existentes que usaban Infallible funcionan sin cambios con el nuevo tipo. Es una decisión de compatibilidad relevante, porque evita que el ecosistema quede dividido entre bibliotecas que usan una u otra forma de expresar la misma idea.
La importancia del tipo never en Rust se aprecia mejor en el diseño de bibliotecas genéricas. Una biblioteca que define un rasgo con un tipo de error asociado puede, ahora, permitir que una implementación concreta declare que nunca falla, y el compilador puede razonar con esa información para eliminar ramas imposibles. El resultado es código más expresivo y, en algunos casos, más eficiente, sin recurrir a tipos auxiliares definidos por cada proyecto.
Una década y cinco intentos fallidos
La historia del tipo never es una de las más largas del desarrollo de Rust. La propuesta formal que lo elevaba a tipo de pleno derecho, el RFC 1216, data de 2015, el mismo año en que se publicó la versión 1.0 del lenguaje. El seguimiento de su implementación se abrió poco después, y desde entonces la funcionalidad estuvo disponible en el canal nightly detrás de una bandera experimental.
El problema nunca fue implementar el tipo en sí, sino una cuestión aparentemente secundaria: el llamado fallback, es decir, el tipo que el compilador asigna a una expresión divergente cuando no hay ninguna otra pista para inferirlo. Durante años, el compilador resolvía esas situaciones asignando el tipo unidad, que se escribe con un par de paréntesis vacíos y representa la ausencia de un valor significativo. Estabilizar el tipo never de forma coherente implicaba cambiar ese comportamiento para que el fallback fuera el propio tipo never.
Ese cambio, que en teoría resulta más limpio, en la práctica alteraba la inferencia de tipos en código que ya compilaba. Hay patrones, sobre todo relacionados con funciones genéricas cuyo tipo de retorno se infiere a partir del contexto, en los que el resultado de la inferencia cambiaba de forma silenciosa. En algunos casos el código dejaba de compilar; en otros, y esto era lo más delicado, el compilador elegía un comportamiento distinto en tiempo de ejecución, especialmente en código inseguro.
Cada intento de estabilización tropezó con esas regresiones. La cobertura del proyecto contabiliza cinco intentos fallidos a lo largo de la década, algunos de ellos revertidos después de que las pruebas a gran escala sobre el ecosistema de crates detectaran roturas. Rust somete los cambios delicados a ejecuciones de crater, una herramienta que compila y prueba buena parte de los paquetes públicos con el compilador modificado para medir el impacto real. En el caso del tipo never, esas ejecuciones mostraron repetidamente que el cambio de fallback afectaba a demasiado código como para introducirlo sin más.
La salida llegó por el camino de las ediciones. Rust organiza los cambios incompatibles en ediciones, conjuntos de reglas que cada crate elige de forma explícita y que permiten que código escrito con distintas ediciones conviva y se enlace sin problemas. La edición 2024, estabilizada con Rust 1.85 a comienzos de 2025, cambió el fallback de las expresiones divergentes al tipo never solo para el código que optara por ella. Ese paso intermedio permitió que el ecosistema fuera adaptándose de forma gradual, con avisos del compilador sobre los patrones que dependían del comportamiento antiguo.
Rust 1.100 completa el recorrido. El tipo never se convierte en el tipo de fallback también en las ediciones 2015, 2018 y 2021, de manera que todas las ediciones comparten ya la misma semántica. Ese es, según reconoce el propio proyecto, el principal riesgo de ruptura de esta versión.
El cambio de fallback como riesgo para el código existente
El anuncio de la versión indica que la mayor parte del código no se verá afectado, pero advierte de que algunos casos pueden dejar de compilar. El ejemplo que menciona el proyecto es el de ignorar el resultado de una función que devuelve un parámetro genérico: si ese parámetro no está restringido por ningún otro elemento del código y la expresión diverge, el compilador antes elegía el tipo unidad y ahora elige el tipo never, lo que puede provocar que un rasgo requerido no esté implementado para el nuevo tipo. También es posible que cierto código pase a marcarse como inalcanzable, lo que genera avisos nuevos.
Para equipos que mantienen bases de código grandes en ediciones antiguas, esta circunstancia convierte la actualización en algo más que un trámite. La migración entre ediciones de Rust se había presentado tradicionalmente como el mecanismo que garantizaba que nadie se veía obligado a adaptar su código por una nueva versión del compilador. En esta ocasión, el proyecto ha optado por aplicar un cambio de semántica a ediciones antiguas, algo poco frecuente, tras haber dejado un periodo de transición con avisos y tras haber comprobado, según su propia evaluación, que el impacto residual era asumible.
El anuncio añade que muchas dependencias afectadas ya cuentan con correcciones publicadas, por lo que recomienda actualizarlas. En la práctica, esto significa que un proyecto que falle al compilar con Rust 1.100 puede deberse no a su propio código, sino a una versión antigua de un crate que todavía depende del fallback anterior. La primera medida razonable, por tanto, es revisar si existen versiones más recientes de las dependencias implicadas.
Quienes vienen de otros lenguajes con sistemas de tipos expresivos reconocerán el concepto. Lenguajes funcionales modernos, como el lenguaje Gleam, también apuestan por un sistema de tipos que codifica en la propia firma de las funciones qué puede fallar y qué no. La diferencia en Rust es que el tipo never debía encajar en un lenguaje con diez años de código en producción, lo que explica la prudencia con la que se ha abordado.
Cargo estrena la edad mínima de publicación de dependencias
La segunda gran novedad de la versión está en Cargo. Con la estabilización del RFC 3923, el gestor de paquetes puede ignorar versiones de crates cuya fecha de publicación sea más reciente que un umbral configurable. Si un equipo establece, por ejemplo, un plazo de tres días, Cargo no seleccionará al resolver dependencias ninguna versión publicada en las últimas 72 horas, y elegirá en su lugar la versión compatible más reciente que supere ese plazo.
La configuración se realiza en el archivo de configuración de Cargo, dentro de la sección dedicada a los registros, mediante una opción llamada global-min-publish-age que admite valores expresados en unidades de tiempo legibles. Según el anuncio, Cargo informa de las versiones que ha retenido por no cumplir la edad mínima, de modo que los desarrolladores pueden ver qué actualizaciones se están aplazando. Para casos puntuales, existe una variable de entorno que permite saltarse la comprobación en una actualización concreta.
La función es opcional y su valor por defecto es cero, lo que significa que nada cambia para quienes no la configuren. El diseño incluye además varias reglas para evitar efectos indeseados. La primera es que las versiones ya fijadas en el archivo Cargo.lock se respetan aunque sean más recientes que el umbral: la edad mínima de publicación solo actúa cuando Cargo debe elegir una versión nueva, no cuando reproduce una resolución ya registrada. Esto evita que un proyecto deje de compilar de repente por activar la opción.
La segunda regla es que la función se ignora en cargo install, el comando que instala binarios desde el registro. El proyecto indica que, en ese caso, la alternativa para quien quiera controlar la antigüedad de lo que instala es fijar explícitamente la versión. La tercera es que las versiones que no tienen fecha de publicación registrada en el índice no se retienen, una decisión pensada para no bloquear paquetes antiguos o registros alternativos que no aportan ese dato.
El propio proyecto Rust subraya en su anuncio que estos periodos de espera no constituyen una defensa completa frente a los ataques a la cadena de suministro. Son, en su planteamiento, una capa adicional que reduce la ventana de exposición, no un sustituto de la revisión de dependencias ni de las auditorías de seguridad.
Por qué esperar unos días puede frenar un ataque
La lógica de la edad mínima de publicación se basa en una observación empírica: la mayoría de los paquetes maliciosos que llegan a un registro público se detectan y se retiran en un plazo relativamente corto, a menudo de horas o pocos días. Los atacantes cuentan con que, en ese intervalo, los sistemas de integración continua y los desarrolladores que actualizan dependencias descarguen la versión comprometida de forma automática.
Si un proyecto se niega a adoptar versiones que no hayan pasado cierto tiempo en el registro, la ventana de exposición se reduce drásticamente. Cuando la versión maliciosa alcanza la edad mínima, es probable que ya haya sido identificada por investigadores, por los propios mantenedores o por los sistemas de análisis del registro, y retirada. El periodo de espera no detecta el código malicioso por sí mismo; simplemente da tiempo a que otros lo detecten.
Los ataques a la cadena de suministro de software han sido una preocupación creciente en todos los ecosistemas. En el de Rust, el caso más conocido es el del crate rustdecimal, retirado en mayo de 2022. Su nombre imitaba al del popular crate rust_decimal para aprovechar errores tipográficos de los desarrolladores, una técnica conocida como typosquatting. El paquete funcionaba como el original salvo por una función añadida que descargaba y ejecutaba código malicioso en ciertos entornos de integración continua. El aviso de seguridad del proyecto Rust recomendaba considerar comprometido cualquier entorno de integración continua que hubiera dependido de ese crate. Según los datos del aviso, había acumulado menos de 500 descargas desde su publicación, en marzo de ese año.
En el ecosistema de JavaScript los incidentes han sido más numerosos y de mayor escala. En septiembre de 2025, un gusano bautizado como Shai-Hulud comprometió cientos de paquetes de npm: robaba credenciales de publicación de los desarrolladores afectados y las usaba para publicar versiones infectadas de otros paquetes que esos mismos desarrolladores mantenían, propagándose de forma automática. El código malicioso se ejecutaba en el momento de la instalación mediante los scripts de ciclo de vida del gestor de paquetes. Las estimaciones sobre su alcance superaron los 500 paquetes, entre ellos algunos de uso muy extendido. Casos anteriores, como el del paquete event-stream en 2018, ya habían demostrado que basta con que un mantenedor ceda el control de un proyecto popular a un tercero malintencionado para que el código comprometido llegue a miles de proyectos.
Lo común en estos incidentes es que el daño se concentra en las primeras horas o días tras la publicación. De ahí que la idea de imponer un periodo de espera haya ganado adeptos rápidamente entre responsables de seguridad.
Una tendencia que se extiende entre gestores de paquetes
Cargo no es el primer gestor de paquetes que adopta esta medida. En el ecosistema de JavaScript, pnpm incorporó una opción llamada minimumReleaseAge que permite ignorar versiones publicadas más recientemente que un número de minutos configurable, y el propio cliente de npm añadió posteriormente una opción equivalente, min-release-age, expresada en días. En Python, el gestor uv ofrece la opción exclude-newer, que permite excluir paquetes publicados después de una fecha concreta o, en versiones recientes, dentro de un plazo relativo.
Las implementaciones difieren en los detalles, como la unidad de medida, la existencia de listas de excepciones o el comportamiento con dependencias transitivas, pero comparten la misma filosofía. Varias de ellas han tenido que afrontar problemas prácticos similares: herramientas automáticas de actualización de dependencias que proponen versiones que el gestor luego rechaza, o paquetes internos que necesitan publicarse y consumirse de inmediato. La decisión de Cargo de respetar el archivo de bloqueo y de ofrecer una vía para saltarse la comprobación puntualmente responde a ese tipo de fricciones.
La convergencia entre ecosistemas tiene una lectura clara: los responsables de las herramientas asumen que los registros públicos seguirán siendo objetivo de ataques y que la defensa no puede depender únicamente de la vigilancia de los propios registros. Mover parte de la responsabilidad al lado del consumidor, con políticas configurables, es una forma de repartir el riesgo.
Los fallos de seguridad no se limitan a las dependencias de terceros, por supuesto. Incidentes como el fallo SSHole en OpenSSH con musl muestran que también las interacciones entre componentes de sistema bien establecidos pueden abrir puertas inesperadas. Pero en el caso de los gestores de paquetes, la automatización de las actualizaciones convierte cualquier versión maliciosa en un problema que se propaga a gran velocidad, y por eso los periodos de espera se han convertido en una recomendación cada vez más habitual.
Mejor detección de dependencias no usadas
Además de la edad mínima de publicación, Cargo mejora en esta versión la detección de dependencias que figuran en el manifiesto de un proyecto pero que el código no utiliza. Según el anuncio, Cargo emite ahora avisos sobre esas dependencias, controlables a través de la sección de lints de Cargo en el manifiesto.
El diseño es deliberadamente conservador. Los avisos solo aparecen cuando se compilan todos los objetivos que podrían usar una dependencia, de modo que compilar un único binario de un proyecto con varios no generará falsos positivos sobre dependencias que usa otro binario. Tampoco se muestran avisos para las dependencias de desarrollo.
Esta función, aunque menos llamativa que las anteriores, tiene también una lectura de seguridad. Cada dependencia añadida es una superficie de ataque potencial y un elemento más que auditar. Eliminar las que no se usan reduce el tiempo de compilación, simplifica el árbol de dependencias y disminuye el número de paquetes de terceros cuyo código se ejecuta durante la compilación, por ejemplo a través de scripts de construcción o macros procedurales.
Cargo reorganiza asimismo el directorio de compilación. El anuncio explica que el hash que identifica cada configuración de compilación se aplica ahora de forma coherente y que el directorio se organiza por etapas, lo que reduce las colisiones de caché cuando se compila con distintas combinaciones de características y hace más fiable compartir ese directorio entre varios árboles de trabajo de git. El proyecto advierte, no obstante, de que este cambio puede romper procesos de compilación o pruebas que incluyeran soluciones alternativas para el comportamiento anterior de la caché.
La API de asignadores llega al canal estable
Otra de las piezas que acompaña a esta versión es la estabilización de la API de asignadores en Rust, uno de los trabajos pendientes más veteranos de la biblioteca estándar. El anuncio oficial confirma que el rasgo Allocator pasa a ser estable, lo que permite a los autores de bibliotecas definir asignadores de memoria personalizados y usarlos con estructuras de la biblioteca estándar.
El alcance inicial es, sin embargo, limitado. Según el proyecto, por ahora solo Vec y Box aceptan asignadores personalizados. Se estabilizan, además del rasgo, los tipos Global y System, así como un conjunto de métodos para construir vectores y cajas en un asignador concreto, recuperar sus partes en bruto junto con el asignador o consultar qué asignador utilizan. Otras colecciones, como las tablas hash o los contadores de referencias usados como contenedores, quedan fuera de este primer paso en lo que respecta a aceptar asignadores propios.
Para el desarrollo de sistemas, motores de juegos, software embebido o aplicaciones de alto rendimiento, la posibilidad de controlar de dónde sale la memoria de cada estructura es relevante. Permite, por ejemplo, usar asignadores de tipo arena que liberan de golpe toda la memoria de una fase de procesamiento, o asignadores especializados para ciertos tamaños de objeto. Hasta ahora, quien necesitaba esa flexibilidad debía recurrir al canal nightly o a bibliotecas externas que reimplementaban las colecciones básicas.
Otras novedades de la biblioteca estándar
La versión 1.100 incluye también un conjunto de funciones menores estabilizadas. Entre ellas figura DropGuard, en el módulo de memoria del núcleo, que ejecuta una función de cierre cuando sale de ámbito y que puede descartarse para recuperar el valor sin ejecutar ese cierre. Es un patrón que muchos proyectos implementaban por su cuenta para garantizar tareas de limpieza.
Se añaden además métodos como toggle para valores booleanos, take y map para Box, map para los contadores de referencias Rc y Arc, y from_fn para construir vectores a partir de una función. Las cadenas, los slices y las rutas reciben métodos para recortar prefijos y sufijos, y UnsafeCell incorpora métodos adicionales para trabajar con su contenido. En Windows se añaden funciones para acceder al hilo principal de un proceso hijo y para controlar cómo se muestra su ventana.
Ninguna de estas incorporaciones cambia por sí sola la forma de programar en Rust, pero en conjunto reducen la cantidad de código auxiliar que los proyectos deben escribir para tareas comunes, en la línea de mejoras incrementales que el proyecto ha seguido durante los últimos años.
La situación actual tras el lanzamiento
Al momento de escribir estas líneas, dos días después de la publicación, Rust 1.100.0 está disponible en el canal estable y puede instalarse con rustup. El tipo never figura como estable en la documentación de la biblioteca estándar, y el proyecto considera completado el objetivo que tenía abierto para su estabilización.
La edad mínima de publicación en Cargo está disponible desde esta versión, pero, al ser opcional y con valor por defecto cero, su adopción dependerá de que los equipos decidan configurarla. No hay, por ahora, indicaciones del proyecto sobre un cambio en ese valor por defecto. Tampoco hay constancia de que el registro crates.io vaya a modificar sus propios procesos a raíz de esta función, que actúa exclusivamente en el lado del cliente.
Respecto a la API de asignadores, su estabilización abre la puerta a que en próximas versiones más colecciones acepten asignadores personalizados, aunque el anuncio no fija un calendario para ello. El cambio de fallback del tipo never, por su parte, será la principal fuente de incidencias que los equipos reporten en las próximas semanas, a medida que actualicen sus cadenas de herramientas. El proyecto ya ha señalado que muchas dependencias afectadas disponen de versiones corregidas.
Impacto para los equipos de desarrollo
Para la mayoría de los proyectos, la actualización a Rust 1.100 debería ser transparente. Pero el cambio de fallback convierte esta versión en una de las que conviene probar antes de desplegar, especialmente en organizaciones que mantienen código en ediciones antiguas, que dependen de versiones fijadas de crates con años de antigüedad o que trabajan con código inseguro donde la inferencia de tipos puede tener consecuencias en tiempo de ejecución.
La estrategia más prudente consiste en actualizar primero el compilador en una rama de pruebas, compilar todo el espacio de trabajo con todos sus objetivos y ejecutar la batería de pruebas completa. Si aparecen errores relacionados con rasgos no implementados para el tipo never, el primer paso es identificar si provienen del propio código o de una dependencia; en este segundo caso, la recomendación del proyecto es buscar una versión más reciente de la dependencia. Si el error está en el código propio, normalmente basta con anotar explícitamente el tipo que antes se infería de forma implícita.
Conviene prestar atención también a los nuevos avisos de código inalcanzable y a los avisos de dependencias no usadas. Ninguno de ellos rompe la compilación por defecto, pero en proyectos que tratan los avisos como errores en su integración continua pueden provocar fallos que no tienen que ver con la corrección del programa. Ajustar la configuración de lints antes de la actualización evita sorpresas.
En cuanto a la edad mínima de publicación, la decisión de activarla y el plazo elegido dependen del perfil de cada equipo. Un plazo de pocos días ofrece protección frente a la mayoría de incidentes conocidos sin retrasar demasiado la llegada de correcciones. Sin embargo, existe un dilema evidente: si una dependencia publica una corrección urgente de seguridad, el periodo de espera también la retrasará. Para esos casos, la variable de entorno que permite saltarse la comprobación de forma puntual resulta esencial, y los equipos deberían documentar internamente cuándo y cómo usarla.
Las organizaciones con registros privados o paquetes internos deberán comprobar además cómo interactúa la función con su infraestructura, teniendo en cuenta que las versiones sin fecha de publicación en el índice no se retienen. Y quienes distribuyan herramientas mediante cargo install deben recordar que allí la opción no tiene efecto, por lo que la vía recomendada es fijar versiones concretas.
Cómo prepararse para la actualización
Más allá de las pruebas técnicas, la llegada de esta versión es una buena ocasión para revisar prácticas. Mantener las dependencias razonablemente al día reduce la probabilidad de que un cambio como el del fallback afecte a una versión antigua que ya no recibe correcciones. Revisar periódicamente el árbol de dependencias, ahora con la ayuda de los avisos de Cargo sobre las que no se usan, permite podar paquetes innecesarios.
En el plano de la seguridad, la edad mínima de publicación encaja bien junto a otras medidas: la revisión de los cambios en dependencias antes de aceptarlos, el uso de bases de datos de avisos de seguridad del ecosistema y la limitación de los permisos de los entornos de integración continua. El caso de rustdecimal mostró que los atacantes apuntan precisamente a esos entornos, donde suelen residir credenciales valiosas.
Para quienes están empezando con el lenguaje o quieren consolidar sus fundamentos antes de abordar conceptos como el tipo never o los asignadores personalizados, el libro oficial del proyecto sigue siendo la referencia más citada. The Rust Programming Language, 2.ª edición, escrito por Steve Klabnik y Carol Nichols y publicado por No Starch Press en 2023, cubre la edición 2021 del lenguaje y explica con detalle el sistema de tipos, la gestión de la memoria y el uso de Cargo. Aunque no recoge las novedades de esta versión, proporciona la base necesaria para entender por qué el cambio de fallback o la API de asignadores tienen la relevancia que tienen. Quienes trabajen con cálculo numérico encontrarán útil, además, repasar cómo funcionan los números de punto flotante, un terreno donde el sistema de tipos de Rust también impone sus propias reglas.
Lecciones de un lanzamiento simbólico
La versión 1.100 deja varias lecturas sobre la forma en que evoluciona Rust. La primera es que el proyecto sigue anteponiendo la estabilidad a la rapidez. Diez años para estabilizar un tipo cuya utilidad nadie discutía pueden parecer excesivos, pero el recorrido muestra un proceso que prefirió retroceder varias veces antes que romper código ajeno sin preaviso. El uso de las ediciones como paso intermedio, primero limitando el cambio a quien optara por la edición 2024 y después extendiéndolo a todas, se ha convertido en un modelo de cómo introducir cambios delicados en un lenguaje maduro.
La segunda lectura es que ese modelo tiene límites. Aplicar el nuevo fallback a ediciones antiguas supone aceptar que la garantía de que el código de una edición nunca se rompe admite excepciones cuando el beneficio es claro y el impacto se ha medido. El proyecto lo ha comunicado de forma explícita, pero es un precedente que los equipos con grandes bases de código antiguas tendrán en cuenta.
La tercera lectura concierne a la seguridad del ecosistema. La edad mínima de publicación refleja un consenso que se ha extendido entre gestores de paquetes de distintos lenguajes: los registros públicos son un objetivo prioritario, y las herramientas deben ofrecer a los consumidores mecanismos sencillos para protegerse. Que Cargo la incorpore como función opcional, con reglas pensadas para no romper flujos existentes, muestra la preferencia del proyecto por soluciones graduales que los equipos puedan adoptar a su ritmo.
Conclusiones
Rust 1.100.0 resuelve una de las deudas más antiguas del lenguaje con la estabilización del tipo never, que ahora puede usarse en cualquier posición y que pasa a ser el tipo de fallback de las expresiones divergentes en todas las ediciones. El cambio, fruto de una década de trabajo y de cinco intentos previos que no llegaron a buen puerto, mejora la expresividad del sistema de tipos y unifica la semántica entre ediciones, a cambio de un riesgo de ruptura que el propio proyecto reconoce y que obliga a probar la actualización con cuidado.
En paralelo, Cargo incorpora la edad mínima de publicación de dependencias, una medida opcional que permite ignorar versiones recién publicadas para reducir la exposición a paquetes maliciosos. La función respeta las versiones fijadas en el archivo de bloqueo, no se aplica a cargo install y no retiene versiones sin fecha de publicación, y llega acompañada de una mejor detección de dependencias no usadas. Según el propio proyecto, no es una defensa completa, pero sí una capa adicional alineada con lo que ya ofrecen otros gestores como pnpm, npm o uv.
La estabilización de la API de asignadores, aunque limitada por ahora a Vec y Box, y un conjunto de mejoras menores en la biblioteca estándar completan una versión que combina cambios de fondo con utilidades prácticas. Para los equipos, la recomendación es clara: probar la actualización en un entorno aislado, revisar las dependencias que puedan depender del fallback antiguo y valorar si la edad mínima de publicación encaja en su política de seguridad. El número redondo es simbólico, pero los cambios que trae esta versión tendrán efectos concretos en el día a día de quienes programan en Rust.