Releases

Especificado. El diseño es dec-0133, LOCKED. El bloque releases: del model, el guard check:releases y la vista generada existen en el repositorio; la página sigue especificada mientras dec-0124 (cobertura de docs de cada nodo) esté PROPOSED. Ningún release está publicado todavía: cada uno espera el pass de su definition of done.

Qué es un releaseCopiar enlace

Un release es un checkpoint del tren de versiones atado al roadmap. Vive en styx.model.yml, en la lista releases:, y cada entrada dice:

• qué nodos del roadmap incluye, en orden de trabajo (y cuáles entran sólo si llegan);
• de qué releases depende. Es el único orden que existe: no hay fechas, plazos ni estimaciones, y el guard rechaza cualquier campo o valor con forma de fecha o de duración;
• su definition of done: una lista de gate items. Cuando todos pasan, con la evidencia firmada por alguien distinto del autor, el release se puede publicar;
• su canal (nightly o stable, no hay más), si es un alpha o beta y si es privado o público, y qué items tienen que pasar para abrirlo;
• qué ADRs tienen que estar lockeados para publicarlo;
• su versión. Los alfas son 0.0.0-alpha.N: el tren sigue en 0.0.0 en estado alfa (dec-0123) y el primer v0.y.z lo corta waxin más adelante. Tener versión no publica nada.

Los releases de hoyCopiar enlace

El estado, el contenido y el DoD de cada uno están en la vista generada Releases. En resumen:

1. alpha.0 (0.0.0-alpha.0): el esqueleto desplegado en el Coolify de waxin, privado. Empieza por la aplicación del sitio de documentación (desplegar la documentación).
2. alpha.1 (0.0.0-alpha.1): el MVP, la primera vertical VOD web sobre la biblioteca real.
3. alpha.2 (0.0.0-alpha.2): lo que va justo detrás del MVP.

Después de alpha.1 se decide con waxin qué entra en v0.2, beta o lo que siga.

Cómo se corta un alfaCopiar enlace

1. bun run release:plan -- --prerelease alpha dice qué alfa toca: la N siguiente a la mayor de los tags v0.0.0-alpha.*, o 0.0.0-alpha.0 si no hay ninguno. Sale en rojo si esa versión no es la version de un release de styx.model.yml, o si ya hay un stable cortado (el esquema posterior no está decidido).
2. bun run release:version -- --prerelease alpha escribe las notas del tren (## v0.0.0-alpha.N en el changelog del tren, bajo release/) y los changelogs de los componentes con cambios. Las versiones de componente no se tocan: siguen congeladas en 0.0.0 hasta el primer v0.y.z.
3. Con el DoD del release en pass, el mantenedor pone el tag v0.0.0-alpha.N y el build lleva ese tren dentro: bun run release:build --train 0.0.0-alpha.N, desde un árbol limpio (un fichero sin versionar que no esté ignorado también lo ensucia) y con el tag apuntando al commit que se construye; si no, el build se niega.

Cómo viaja un alfa por el canal stable (P5 de dec-0133) sigue sin decidir: hoy el manifiesto de stable sólo acepta X.Y.Z. El de nightly acepta un alfa cortado (alpha.0 va por ese canal), pero ningún workflow publica todavía un tag de alfa.

Cómo cambia un releaseCopiar enlace

• Se edita styx.model.yml, nunca la vista: bun run docs:gen la regenera.
• bun run check:roadmap corre check:releases, que comprueba la forma, las referencias, que el orden de releases no contradice el grafo de dependencias, que un nodo está en un solo release y que nada se marca publicado o público sin el pass de sus items.
• Un nodo nuevo en un release necesita una página a mano que lo cite (dec-0124), igual que cualquier nodo del roadmap.

Lo que faltaCopiar enlace

• Que cada página diga desde qué release está disponible lo que describe, derivado del model (dec-0133 D4). Hoy el campo since del contrato es siempre null.
• Que axon conozca la entidad: hoy la valida y la pinta el lado styx.