Summary
Define what a version/release is for the emsemioverse and implement the concept. Currently there is no concept of a named state of the project — no “v0.1” or release artifact.
Motivation
The semiotic-versioning spec defines version semantics for individual specifications, but there is no concept of a project-level release. In software, releases are named states of the project published for external consumption. In the emsemioverse, the analog would be: a named state of the published site + repository where specific milestones are met and the interaction surface is at a known level of capability.
This connects to Goal 005 (semantic pipeline): the pipeline’s output is the published artifact, and releases mark meaningful states of that artifact.
Steps
- Research: what does a “release” mean for a knowledge repository (not just software)? Check TCCC, disaster response, and FOSS practices per decision 0007.
- Write a semiotic-release term (or extend semiotic-versioning).
- Define what a release contains: content snapshot, predicate graph state, satisfaction metrics, published site state.
- Define release cadence (if any) or trigger conditions.
- Create first release.
Done when
- Release concept defined (term or extension to semiotic-versioning)
- At least one release created with a named version
Dependencies
None — but benefits from Goal 005 (semantic pipeline) being advanced.
Log
2026-03-08 — Created from gap analysis. Versions/releases is the only one of the 12 researched PM practices with no concept AND no plan.