Versiones, releases y monorepos

Tags y releases

Un tag es una etiqueta fija que marca un commit concreto, normalmente para señalar una versión publicada. A diferencia de una rama, no se mueve.

git tag v1.4.0                 # tag ligero en el commit actual
git tag -a v1.4.0 -m "Release 1.4.0"   # tag anotado (con autor y mensaje)
git push origin v1.4.0         # publica el tag (push no envía tags por defecto)
git push origin --tags         # publica todos los tags

Una release es la publicación formal de una versión: el tag + notas de cambios (changelog) + artefactos (binarios, paquetes). En GitHub se crea a partir de un tag.

Versionado semántico (SemVer)

SemVer asigna a cada versión tres números: MAJOR.MINOR.PATCH (p. ej. 2.4.1). Cada uno comunica el tipo de cambio:

• MAJOR: cambios incompatibles (rompen la API pública). Subir MAJOR reinicia MINOR y PATCH a 0. 2.4.1 -> 3.0.0.
• MINOR: nueva funcionalidad compatible hacia atrás. Reinicia PATCH a 0. 2.4.1 -> 2.5.0.
• PATCH: correcciones de bugs compatibles. 2.4.1 -> 2.4.2.

~1.2.3  -> permite PATCH:  >=1.2.3 <1.3.0
^1.2.3  -> permite MINOR:  >=1.2.3 <2.0.0   (por defecto en npm)

Encaja con Conventional Commits: fix: -> PATCH, feat: -> MINOR, feat!: / BREAKING CHANGE -> MAJOR.

Monorepo vs polyrepo

• Polyrepo: un repositorio por proyecto/paquete. Aislamiento claro y permisos por repo, pero compartir código y coordinar cambios entre repos es más costoso.
• Monorepo: muchos proyectos/paquetes en un solo repositorio. Facilita compartir código, refactors atómicos que cruzan paquetes y una única fuente de verdad. A cambio, exige herramientas (Nx, Turborepo, workspaces de pnpm/npm) y una buena CI para no construir/probar todo en cada cambio.

mi-monorepo/
├── package.json        # workspaces
├── apps/
│   ├── web/
│   └── api/
└── packages/
    ├── ui/
    └── utils/

No hay "ganador" universal: el monorepo brilla cuando los paquetes están muy acoplados y se versionan/despliegan juntos; el polyrepo, cuando son independientes y los gestionan equipos separados.