Versiones¶
Estado actual¶
| Componente | Versión | Estado | Alcance |
|---|---|---|---|
| Evidence Backbone y Research | v0.9.0 |
Línea base estable de publicación | Fuentes, compatibilidad de claims, estado del arte DI, PULSE y agenda con madurez preservada |
| Candidato fuente | v0.9.0-rc.1 |
Ratificado, fusionado, desplegado y promovido | Fuente trazable de la release estable v0.9.0 |
| Portal bilingüe anterior | v0.8.2 |
Estable e histórico | Localización española, claridad para negocio y búsqueda independiente ES/EN |
| Línea base bilingüe anterior | v0.8.1 |
Estable e histórica | Rutas ES/EN completas, interfaz localizada y gates contra deriva de traducción |
| Candidato bilingüe fuente | v0.8.1-rc.1 |
Ratificado, fusionado, desplegado y promovido | Fuente trazable de la release estable v0.8.1 |
| Portal integrado | v0.8.0 |
Estable editorial y técnicamente | Build reproducible, navegación, trazabilidad, gates y límites de autoridad |
| Gobernanza CDI-BoK | v0.2.0 |
Aprobada y normativa | Arquitectura, autoridad, claims, marca y Sprint 0 |
| Portal técnico | v0.3.0-rc.1 |
Integrado y desplegado | MkDocs, navegación, CI/CD, checks y dominio personalizado |
| Núcleo fundacional | v0.4.0 |
Estable | Constitución, fronteras CDI, glosario, dominios y especificación PULSE |
| Práctica y evidencia | v0.5.0-rc.1 |
Candidato desplegado, no ratificado | Catálogo y primer caso B2B instrumentado, sin outcome observado |
| Aprendizaje y experiencia | v0.6.0-rc.1 |
Candidato ratificado y desplegado | Portada orientada a resultados, cinco módulos y Decision Brief |
| Calidad y medición | v0.7.0-rc.1 |
Candidato ratificado y desplegado | Decision Quality, seis lentes, anti-métricas y Measurement Record |
| Patrones conversacionales | v0.8.0-rc.1 |
Candidato ratificado, fusionado y desplegado | Cinco patrones, seis anti-patrones, lenguaje, plantilla y demostración B2B detenida |
La versión del portal no eleva automáticamente la madurez doctrinal del contenido. Infraestructura, conocimiento y evidencia pueden evolucionar a ritmos distintos, pero siempre deben conservar trazabilidad.
Política vigente¶
- Las releases estables requieren tag inmutable y GitHub Release.
- Los candidatos se trazan mediante nota, changelog, manifiesto, PR, SHA de merge, validación y despliegue. Solo reciben tag cuando el owner autoriza explícitamente congelarlos como pre-release inmutable.
- Ratificación, despliegue y estabilidad son estados diferentes: un candidato ratificado y desplegado no se vuelve estable automáticamente.
decision.javierforero.comuestra el último build público fusionado; la versión del portal no eleva la autoridad ni la fuerza de evidencia de todos sus contenidos.- Borradores no aparecen en navegación estable.
- El español permanece canónico durante
0.x; cada página inglesa se vincula a su fuente, versión y hash en un registro controlado. - El selector de versiones web se incorporará cuando existan al menos dos releases históricas útiles para el lector.
ADR-022 sustituye la regla inicial de ADR-005 y evita crear tags retrospectivos ambiguos.
El registro controlado governance/releases/index.yml conserva la
línea completa. Los RC históricos permanecen intencionalmente sin tag;
v0.8.0, v0.8.1, v0.8.2 y v0.9.0 reciben sus referencias inmutables
únicamente desde gates posteriores al merge gobernados por ADR-024, ADR-026,
ADR-027 y ADR-029. v0.9.0-rc.1 permanece sin tag como candidato fuente
promovido; la release estable no eleva automáticamente la autoridad ni la fuerza
de evidencia de su contenido.
Por qué no existe un v0.1.0 posterior
La hoja de ruta inicial nombró la salida de Sprint 2 como v0.1.0, pero la secuencia ya había publicado v0.2.0 y v0.3.0-rc.1. ADR-014 asignó v0.4.0-rc.1 al candidato; ADR-017 registra su ratificación y promoción estable a v0.4.0.
Historial¶
Consulte el CHANGELOG.md y las releases del repositorio.