Estás publicando en abierto antes de 1.0. ¿Qué número de versión le dice a un desconocido si debe esperar, probarlo con una versión fijada o usarlo libremente? El semver estándar da una sola respuesta para los tres: “la major es cero, cualquier cosa puede pasar”. Eso no es información suficiente para planificar.

El arreglo no requiere cambiar semver. Solo requiere tratar cada casilla por debajo de 1.0 como una etapa distinta del ciclo de vida de la release, con una promesa que todavía le falta. Tres ceros, tres promesas que se ceden. Cada transición devuelve una.

Estoy construyendo Muxon ahora mismo y quiero que el número de versión cargue esa distinción por defecto, para que nadie tenga que leer el changelog para saber en qué etapa está el proyecto.

0.0.0 — nada

El repositorio existe. Los crates compilan. El plan está escrito. No hay implementación. Podrías clonarlo y cargo build tendría éxito; no podrías usarlo para nada.

La promesa que falta: código que haga aquello para lo que está el proyecto.

0.0.x — construyendo la primera cosa usable

Las versiones patch mientras major y minor son cero son pre-MVP. Cada patch aterriza una pieza en el camino hacia un flujo de trabajo usable. Daemon handshake. Estado durable. Binding de directorio. El trait Mux. Las piezas aparecen; el flujo de trabajo todavía no.

Un usuario con 0.0.4 no puede hacer nada de punta a punta. Puede toquetear piezas y verlas funcionar, pero las piezas no se han encontrado. El código existe. El producto no.

La promesa que falta: un flujo de trabajo usable de punta a punta.

0.1.0 — la primera cosa usable

La minor salta de cero a uno cuando hay algo que usar. Para Muxon, eso es muxon --dir . abriendo un workspace ligado al directorio y, al reabrirlo, restaurando el layout. Un usuario puede hacer algo real.

Esta es la puerta hacia la que todo lo anterior estaba construyendo. El MVP, en el sentido honesto de la palabra.

0.x.0 — iterando sobre la cosa usable

Una vez que el MVP existe, las subidas de minor añaden capacidad. Captura con estado. El primer aigent. El capability handshake. Editores. Remote. Cada subida aterriza una rebanada significativa. La compatibilidad aún puede romperse — las superficies absorben uso real y encuentran su forma correcta.

La promesa que falta: superficies estables.

1.0.0 — el congelado

La major salta de cero a uno cuando las superficies ya se han asentado. 1.0.0 no lanza nada nuevo sobre el último 0.x.0. Solo cambia la política: de ahora en adelante, no se rompe nada.

La promesa que se gana: compatibilidad.

Por qué tres ceros

Cada cero, en este esquema, representa una promesa que falta. Cada transición devuelve una.

• 0.0.0 → 0.0.1: ahora existe código.
• 0.0.x → 0.1.0: ahora existe un flujo de trabajo usable.
• 0.x.0 → 1.0.0: ahora existen superficies estables.

El semver estándar colapsa las dos primeras transiciones en una. Cualquier cosa por debajo de 1.0 es “early”. Eso es información suficiente para una librería publicada donde los usuarios pueden esperar a 1.0 antes de adoptarla. No es suficiente para un proyecto publicado en abierto, donde la diferencia entre todavía arrancando y usable pero evolucionando es la diferencia entre ni te molestes todavía y pruébalo, pero fija la versión.

Tres números, tres audiencias:

• 0.0.x se lee como espera.
• 0.x.0 se lee como pruébalo, pero fija.
• 1.x.0 se lee como úsalo libremente; no te romperemos.

Cómo se ve en la práctica

Tres proyectos, la misma regla

Simple

Una CLI de un único binario

Estás escribiendo un grep-alike pequeño. El commit que por primera vez imprime coincidencias es 0.0.1. Añades globbing de ficheros, luego regex, luego --color; cada uno es un bump de patch mientras el flujo de trabajo sigue incompleto. La primera release que puede sustituir a grep en tu propia máquina es 0.1.0. Un mes de uso real después, cuando estás seguro de que el conjunto de flags es con el que quieres vivir, etiquetas 1.0.0 y dejas de romperlo.

Harder

Una librería con plugins

Un host de plugins tiene dos superficies: la API de usuario y la API de plugin. Las dos tienen que congelarse antes de 1.0. Al principio (0.0.x) ni siquiera existe el loader de plugins; todavía estás moldeando la API de usuario. En 0.1.0 lanzas un único plugin incorporado de punta a punta. El rango 0.x.0 es donde la API de plugin muta bajo carga — esta es exactamente la etapa que el esquema nombra, y la etapa donde fijar la versión importa más. Subir a 1.0.0 es la decisión de que ambas superficies se han encontrado con suficientes plugins reales para dejar de cambiar. Sin la distinción 0.0.x / 0.x.0, los primeros autores de plugins no pueden saber si merece la pena invertir.

Wild connection

La soft opening de un restaurante

Un restaurante nuevo recorre el mismo arco. 0.0.x es el acondicionamiento: cocina instalada, menú redactado, personal en formación — nada que un comensal pueda consumir. 0.1.0 es la soft opening: noche de amigos y familia, la primera comida real servida de punta a punta. 0.x.0 son las semanas de ajustar el menú, el emplatado y el flujo de servicio bajo comensales reales pagando dinero real. 1.0.0 es cuando el menú se imprime en cartón real y la cocina deja de cambiar las recetas — la etapa en la que romper “compatibilidad” con los regulares de la semana pasada deja de ser aceptable. Las mismas tres promesas: la cocina existe, la comida existe, el menú es estable.

Rust hacía esto implícitamente

Rust pre-1.0 publicaba software usable. Cada release rompía cosas. La distinción entre Rust-early-bootstrapping (apenas podías escribir nada) y Rust-pre-1.0-tardío (podías escribir código real, pero la stdlib cambiaba) era real, y moldeaba qué tipo de usuario pertenecía a cada versión.

El número de versión no llevaba esa información. La comunidad la sabía por contexto.

La extensión hace el contexto explícito.

El cero es una cosa, no un placeholder

El cero no es un valor por defecto. No es “todavía nada, ignórame”. Es una cosa específica que todavía no existe, y nombrarla tres veces distintas le dice al usuario exactamente qué falta.

Código. Flujo de trabajo. Compatibilidad.

Tres ceros. Tres promesas. Un número que dice lo que dice.