guides

Si mantienes un proyecto de JavaScript, una pregunta práctica vuelve una y otra vez: ¿con qué frecuencia publican realmente una nueva versión las herramientas de las que dependes? La medimos en lugar de suponerla. Usando la API pública de GitHub Releases, recuperamos las últimas 100 versiones de diez proyectos front-end de uso extendido y separamos las versiones estables reales de las preliminares. La dispersión resultó ser mucho mayor de lo esperado, y un proyecto destaca de una forma que cambia cómo debes leer sus números de versión.

El método es deliberadamente simple para que cualquiera pueda repetirlo. Para cada repositorio solicitamos las 100 versiones publicadas más recientes, excluimos los borradores y marcamos una versión como preliminar si la API la señalaba como tal o si su tag contenía alpha, beta, rc, canary, next, experimental, nightly o un sufijo -pre. La cadencia estable es el número de días entre la versión estable más antigua y la más reciente de esa ventana, dividido entre el número de intervalos. Todas las cifras siguientes son reproducibles contra el mismo endpoint público.

La sorpresa: Next.js publica un 88 % de preversiones

El primer resultado es el que nos sorprendió. De las últimas 100 versiones publicadas por Next.js, solo 12 eran estables: el 88 por ciento eran preliminares. No es una señal de inestabilidad, es un modelo de desarrollo deliberado. Next.js publica compilaciones canary casi de forma continua, y las funciones aterrizan ahí mucho antes de aparecer en una versión estable. Si sigues el feed de versiones del repositorio esperando versiones estables, estarás leyendo sobre todo canaries.

Esto importa en la práctica. Un proyecto que publica canaries como versiones de GitHub parecerá enormemente más activo que uno que no lo hace, aunque ambos publiquen versiones estables a un ritmo similar. Juzgar una dependencia por cuántas versiones desfilan te dice algo sobre sus hábitos de publicación, no sobre su estabilidad ni sobre su velocidad de cambio real.

El enfoque opuesto: cero preversiones

En el extremo opuesto, dos proyectos de nuestra muestra no publicaron ninguna versión preliminar en GitHub durante la ventana: Svelte y React Router, ambos a cero. React y Preact quedaron cerca, con un 2 y un 3 por ciento. Estos proyectos o bien no usan versiones preliminares o bien no las publican como versiones de GitHub, así que su feed de versiones se lee como una lista limpia de versiones estables.

• De las últimas 100 versiones de Next.js, solo 12 eran estables: el 88 por ciento eran preliminares (desarrollo canary-first).
• Svelte y React Router publicaron cero versiones preliminares en GitHub en la misma ventana; React y Preact estaban en el 2 y el 3 por ciento.
• La cadencia estable abarca unas ochenta veces: Astro promedió 0.5 días entre versiones estables, React casi 40.
• El recuento de versiones por sí solo induce a error: un proyecto que publica canaries como versiones parece mucho más activo que uno que no lo hace.
• Método: las últimas 100 versiones publicadas en GitHub por repositorio, borradores excluidos, preliminares identificadas por el indicador de la API o por el tag, recogido el 2026-07-27.

Entre los extremos se sitúan los proyectos que usan versiones preliminares de forma sustancial pero no exclusiva: Vue con un 35 por ciento, Angular con un 32, Astro con un 31 y Vite con un 28. Aproximadamente un tercio de lo que publican es una vista previa de algo que aún no está terminado.

Con qué frecuencia salen realmente las versiones estables

Si nos fijamos solo en las versiones estables, los días entre ellas se agrupan con claridad. Astro promedió 0.5 días, Svelte 2.8, Angular 3.2 y Vite 4.3. Next.js se situó en 7.2 días para las versiones estables, Nuxt en 11.9, React Router en 12.5 y Vue en 14.2. Preact promedió 19.1 días, y React 39.7. Cada cifra se mide sobre la ventana propia de cada proyecto, la de sus últimas 100 versiones.

Lo llamativo es la dispersión. Astro publicó una versión estable cada medio día en su ventana, mientras que React promedió casi 40 días entre versiones estables: una diferencia de unas ochenta veces. Svelte, Angular y Vite se agrupan en el rango de dos a cuatro días, Next.js en torno a una semana para las versiones estables, y Nuxt, React Router y Vue entre doce y catorce días.

Rápido no es mejor que lento

Sería un error leer el extremo lento como abandono. La ventana de React se remonta a 2016 precisamente porque publica pocas versiones, grandes y bien separadas, que es exactamente lo que quieres de una biblioteca fundacional de la que dependen miles de paquetes. Una cadencia rápida y una cadencia lenta son respuestas a preguntas distintas, no un ranking.

Para quien mantiene un proyecto, la conclusión práctica tiene que ver con las expectativas. Si dependes de algo del grupo por debajo de la semana, cuenta con actualizaciones frecuentes y pequeñas, y apóyate en actualizaciones de dependencias automatizadas y en un lockfile, porque revisar cada versión a mano no escalará. Si dependes de algo del grupo mensual, las actualizaciones son más raras pero suelen traer más cambios por versión, así que reserva más tiempo para cada una.

Los límites de esta medición

Los límites de esta medición importan tanto como las cifras, así que los exponemos con claridad. La ventana son las últimas 100 versiones, lo que cubre un periodo distinto para cada proyecto: unos diez años para React pero solo unas cinco semanas para Astro. Son instantáneas del comportamiento de publicación actual, no medias históricas comparables. Medimos solo las versiones de GitHub, así que un proyecto que publique preliminares en npm sin crear una versión de GitHub parecerá no tener ninguna. Los monorepos que publican por paquete pueden inflar el recuento de versiones. Y todas las cifras se recogieron el 2026-07-27 y variarán con el tiempo.

Qué conviene retener

La conclusión útil no es que un proyecto sea mejor que otro. Es que el recuento de versiones por sí solo es una mala señal. Antes de juzgar una dependencia por su actividad, comprueba qué proporción de esas versiones es realmente estable, y en qué periodo se publicaron. En esta muestra, hacerlo convirtió un proyecto aparentemente hiperactivo en un calendario de publicación semanal normal envuelto en canaries continuos.