Estabilidad y versiones

Fecha y estado, no número de versión

Las especificaciones de STXT no llevan número de versión. Cada una lleva, en su Metadata, dos cosas:

• Una fecha (Last modif): la de la última modificación de su texto, sea una errata o un cambio de regla. No hay otra versión que la vigente, y una fecha identifica un texto: «STXT-SPEC 2026-09-07» es esa especificación tal como estaba ese día.
• Un estado (Status): cuánta estabilidad se promete. Tiene cuatro valores posibles, en este orden, y solo avanza:

Un cambio incompatible es aquel por el que un documento que era válido deja de serlo o cambia de significado: un cambio deliberado de intención, no una aclaración del texto. La definición normativa de los cuatro estados está en STXT-SPEC §1.1.

El estado de cada especificación

«STXT», dicho por sí solo, es STXT-SPEC, y STXT-SPEC está en Zenith: qué es un documento STXT, cómo se parsea y qué árbol produce no cambiarán. Es lo que respalda la afirmación de arriba.

Por qué Aurora en las otras tres. Esquemas, plantillas y descubrimiento definen qué significa que un documento sea conforme a una definición y dónde se busca esa definición. Son más jóvenes que el núcleo y han tenido menos uso real, y no queremos prometer que no se moverán ni un milímetro antes de saberlo. Aurora es una rebaja consciente respecto a la promesa «válido en toda la línea 1.x» publicada el 2026-08-31 para las cinco, y preferimos decirlo así. Lo que Aurora significa en la práctica:

• Una definición Aurora se apoya sobre un núcleo Zenith: un esquema o una plantilla es un documento STXT y nunca deja de parsear. Lo que podría cambiar es una regla de validación o de resolución, no el documento.
• Un cambio incompatible, si llega, se anuncia siempre, con la fecha en que se hace, qué documentos afecta y cómo se adaptan; nunca es una reinterpretación silenciosa.
• El paso a Zenith de cada una se anunciará con su fecha, y a partir de ahí regirá la misma promesa que para el núcleo.

Qué se congela

Qué no se congela

• El texto de los mensajes de error. Se afinan y se traducen. Lo estable es el código ([CHILD_NOT_DECLARED]), no la frase que lo acompaña; un test o un script que compare mensajes se romperá tarde o temprano.
• Las fachadas de comodidad y los adaptadores de las bibliotecas —lo que existe para escribir menos en el caso fácil, o para atar la biblioteca al sistema de ficheros o al entorno de una plataforma—. Están fuera del alcance normativo y pueden crecer o cambiar de forma dentro de una 1.x; la API de núcleo que envuelven, no.
• La salida de la línea de comandos pensada para personas: el formato del informe de validate, el texto de --help. Lo que va a máquinas —los códigos de salida 0/1/2, --format json y el árbol canónico— sí es estable.
• Las normas de estilo (las secciones marcadas como DEBERÍA en las especificaciones): son recomendaciones y pueden afinarse sin que un documento deje de ser válido.

La fecha de la especificación y la versión del paquete

Las especificaciones llevan fecha y estado, cada una los suyos, independientes de los de las demás: el núcleo está en Zenith y el esquema, la plantilla o el descubrimiento pueden evolucionar a otro ritmo, como XML Schema respecto a XML.

Las bibliotecas llevan la versión de su paquete —@stxt-lang/core en npm, dev.stxt:stxt-core en Maven Central, stxt en PyPI—, en versionado semántico, que sube cuando cambia la biblioteca, no cuando cambia el lenguaje. Un cambio incompatible en la API en memoria es un mayor del paquete, y se anuncia como tal.

La regla que une las dos: la conformidad se declara contra la especificación, no contra el paquete, y se demuestra con el kit de conformidad del repositorio de la especificación. El kit lleva su propia fecha y fija la fecha de cada especificación que certifica; una implementación conforme expone la de STXT-SPEC como constante, SPEC_VERSION, con un valor AAAA-MM-DD. Si @stxt-lang/core va por la 1.3 y dev.stxt:stxt-core por la 1.1, siguen leyendo el mismo STXT: las dos exponen la misma fecha y pasan el mismo kit. Un puerto de terceros hace lo mismo.

Cómo avanza un estado y cómo se anuncia

• Un estado solo avanza: Genesis → Aurora → Zenith → Twilight. Una especificación nunca vuelve a un estado anterior, y Twilight es terminal.
• Cada paso, y cada cambio incompatible en Aurora, se anuncia con su fecha: en la propia especificación (Status y Last modif), en las notas de la publicación del repositorio de la especificación y en esta página. El kit de conformidad se regenera con la fecha nueva, y los puertos que lo pasen la exponen en SPEC_VERSION.
• Una especificación en Zenith no sale de Zenith hacia atrás. Si algún día hiciera falta un cambio incompatible en el núcleo, no habría un «STXT 2»: habría una especificación nueva, con nombre nuevo, conviviendo con esta, y los documentos de hoy seguirían siendo válidos y significando lo mismo.
• Las aclaraciones del texto que no cambian la intención de la especificación solo actualizan Last modif; no cambian el estado ni el significado de ningún documento.