¿Qué significa 0.1.0? Estándares de versionado de software: SemVer, CalVer y ZeroVer explicados

Cuando abres un archivo package.json, Cargo.toml o pyproject.toml y ves números de versión como 1.4.2, 0.1.0 o 24.04, es fácil tratarlos como etiquetas arbitrarias elegidas por el mantenedor.

En realidad, un número de versión es un contrato formal de ingeniería entre el autor de una librería y cada sistema en producción que depende de ella. Malinterpretar ese contrato es una de las formas más rápidas de tumbar una aplicación en vivo con un solo npm update.

Vamos a desglosar las cuatro filosofías de versionado dominantes en la ingeniería de software moderna.

1. SemVer (versionado semántico): MAJOR.MINOR.PATCH

Creado por Tom Preston-Werner (cofundador de GitHub) y formalizado en la especificación SemVer 2.0.0, el versionado semántico lo usan aproximadamente el 90 % de las librerías de código abierto.

Cada versión sigue un formato estricto de tres partes: MAJOR.MINOR.PATCH (por ejemplo, 2.4.1).

   2   .   4   .   1
   │       │       └── PATCH: Backward-compatible bug fixes & security patches
   │       └────────── MINOR: Backward-compatible new features
   └────────────────── MAJOR: Breaking changes (Incompatible API modifications)

Cómo funciona cada incremento

• PATCH (2.4.1 ➔ 2.4.2): solo correcciones de bugs internos, ajustes de rendimiento o parches de seguridad. No se añaden nuevos métodos públicos y se garantiza que el código existente no se rompe.
• MINOR (2.4.2 ➔ 2.5.0): añade nueva funcionalidad de forma retrocompatible (o marca un método antiguo como @deprecated sin eliminarlo). Ten en cuenta que al subir MINOR el contador PATCH vuelve a 0.
• MAJOR (2.5.0 ➔ 3.0.0): indica un cambio incompatible (breaking change). Cambiaron las firmas de funciones, se eliminaron parámetros o se alteraron los tipos de retorno. Actualizar entre versiones MAJOR requiere leer la guía de migración y actualizar el código de tu aplicación.

2. ZeroVer (0.x.x): la advertencia de beta eterna

¿Qué significa realmente 0.1.0 o 0.24.3?

Según la regla 4 de la especificación oficial SemVer 2.0.0:

"La versión mayor cero (0.y.z) es para el desarrollo inicial. Cualquier cosa PUEDE cambiar en cualquier momento. La API pública NO DEBERÍA considerarse estable."

En una librería 0.x.x (a menudo llamada en broma ZeroVer), las reglas estándar se desplazan una posición en la práctica: los mantenedores suelen introducir cambios incompatibles dentro de un salto menor 0.1.0 ➔ 0.2.0.

3. CalVer (versionado por calendario): lanzamientos guiados por el tiempo

No todos los proyectos encajan bien en SemVer. Los sistemas operativos, los navegadores y las grandes plataformas para desarrolladores evolucionan de forma continua en lugar de girar en torno a un único contrato de API. Estos proyectos usan CalVer (YYYY.MM o YY.0M.MICRO).

• Ubuntu Linux: 24.04 LTS significa literalmente abril de 2024. Sabes de inmediato cuándo se lanzó el sistema operativo y cuándo termina su ventana de soporte de 5 años.
• IDEs de JetBrains: 2026.2 significa la segunda versión mayor del año 2026.
• pip y Certbot: usan versiones de calendario YY.M para indicar de un vistazo la antigüedad de una herramienta de despliegue.

4. Versionado por SHA de commit de Git (CI/CD y microservicios)

Si estás construyendo una aplicación web interna o un microservicio que se despliega 15 veces al día con GitHub Actions, subir manualmente de 1.0.14 a 1.0.15 es burocracia inútil.

Los pipelines de DevOps modernos etiquetan las imágenes de Docker y los releases de Sentry directamente con el SHA corto del commit de Git, que es inmutable, o con un híbrido con marca de tiempo:

# Tagging a production container image with Date + Git Commit SHA
GIT_SHA=$(git rev-parse --short HEAD)
IMAGE_TAG="2026.10.25-${GIT_SHA}"
docker build -t registry.czay.dev/api:${IMAGE_TAG} .

Cuando salta una excepción en producción a las 03:00 de la madrugada, no tienes que adivinar a qué corresponde v1.4.9: ejecutas git show a4b8c1f y ves el commit exacto al instante.

Matriz de decisión resumida