Las claves verificadas
- SemVer usa tres números para comunicar cambios mayor, menor y parche en una API pública. Ver evidencia
- Un cambio incompatible aumenta la versión mayor, mientras una funcionalidad compatible aumenta la menor. Ver evidencia
- Los gestores de paquetes usan rangos de versiones para resolver dependencias según las reglas declaradas. Ver evidencia
- Una release reúne una versión del código y notas que ayudan a entender los cambios para quienes la instalan. Ver evidencia
Qué es SemVer
SemVer, abreviatura de Semantic Versioning, es una convención para numerar versiones de software con tres partes: mayor, menor y parche. Una versión como 2.4.1 comunica un orden y también una expectativa sobre el impacto de actualizarla.
También puede servirte: Qué es una variable de entorno y cómo usarla
La convención funciona cuando el proyecto define una API pública: funciones, comandos, formatos o comportamientos que otros clientes usan. Si no hay una interfaz que mantener, el número sigue siendo útil como etiqueta, pero pierde parte de la promesa de compatibilidad.
Qué significa mayor, menor y parche
El número mayor cambia cuando se introduce una modificación incompatible con la API pública. El número menor aumenta al sumar funcionalidad compatible y el número de parche cambia para correcciones compatibles. Cada parte se reinicia cuando cambia una de mayor impacto.
El orden también permite comparar versiones: 2.10.0 es posterior a 2.9.5 aunque el 9 parezca más grande al mirar los caracteres. El prefijo cero suele reservarse para una etapa inicial en la que todavía no se promete estabilidad completa.
Cómo se relaciona con las dependencias
Los gestores de paquetes pueden expresar rangos para aceptar actualizaciones compatibles. Un rango no significa que cualquier versión sea segura por definición: depende de que el proyecto respete SemVer y de que sus pruebas detecten cambios inesperados en la práctica.
Antes de actualizar una dependencia, revisá el changelog, el rango configurado y las pruebas del proyecto. Una versión mayor merece una lectura especial porque puede exigir cambios en el código; una versión menor o de parche también puede revelar un error corregido que conviene incorporar.
Qué revisar antes de publicar una versión
Definí la API pública y anotá si el cambio agrega, corrige o retira comportamiento. Después ejecutá las pruebas, actualizá el número correcto y escribí las notas de la versión con ejemplos de migración cuando una modificación rompa una integración.
La etiqueta de una release debe apuntar al código y a los artefactos que realmente se pueden instalar. Publicar una versión no reemplaza la revisión de seguridad ni las pruebas de compatibilidad, pero un número coherente permite que las herramientas y los equipos entiendan qué esperar.
Qué aporta VisteEsto: Nuestro trabajo en esta nota
VisteEsto traduce cada número de SemVer a una decisión práctica: aceptar una actualización, revisar cambios de API o preparar una migración.
Fuentes, actualizaciones y metodología 3 fuentes
Fuentes consultadas
- Fuente primariaSemantic Versioning 2.0.0
- Fuente primarianpm Docs: About semantic versioning
- Fuente primariaGitHub Docs: About releases
Historial de actualización
- Publicación inicial basada en Semantic Versioning 2.0.0, la documentación de npm y GitHub Releases.
Cómo elaboramos esta nota
Definimos la consulta principal “qué es SemVer y cómo funciona”, contrastamos los datos con 3 fuentes —3 primarias— y revisamos contexto, imágenes y posibles vacíos antes de publicar. Conocé nuestra política editorial y de verificación.
