What is broken
version.txt reads 0.1.2 on both integration and main. The newest tag in the repository is v0.1.1, dated 2026-08-11. The bump to 0.1.2 landed on 2026-09-09 in #59 and was never tagged.
The repository also has no GitHub Releases at all. gh release list returns empty, so even v0.1.1 exists only as a tag.
Where
version.txt, git tags, GitHub Releases
What the specification says, and what happens instead
docs/spec/conformance.md says a deployment that advertises ACS-Core conformance is asserting that about itself, and tells a buyer to test the deployment against the requirements the way they would check any other vendor claim. Doing that requires naming the artifact that was tested.
A claim against "0.1.2" currently resolves to nothing. There is no tag, no release, and no commit a third party can name without reading version.txt history.
The v0.1.1 release commit deliberately decoupled the release version from the spec version, so version.txt moves on its own schedule while schema $id stays at v0.1.0. That decoupling is correct and it also removes the signal that used to make an untagged bump obvious.
Impact on implementers
A second implementer writing a conformance claim cannot state which release they built against. The contributors filing conformance evidence today (#109, #111, #113) are reporting against a tree that has no citable version.
Worth deciding alongside #99, which asks how release-branch versioning works now that sync_version.yml follows integration. A tagging rule and a branch rule are the same decision.
Current Priority Scope
Feeds conformance evidence
What is broken
version.txtreads0.1.2on bothintegrationandmain. The newest tag in the repository isv0.1.1, dated 2026-08-11. The bump to0.1.2landed on 2026-09-09 in #59 and was never tagged.The repository also has no GitHub Releases at all.
gh release listreturns empty, so evenv0.1.1exists only as a tag.Where
version.txt, git tags, GitHub ReleasesWhat the specification says, and what happens instead
docs/spec/conformance.mdsays a deployment that advertises ACS-Core conformance is asserting that about itself, and tells a buyer to test the deployment against the requirements the way they would check any other vendor claim. Doing that requires naming the artifact that was tested.A claim against "0.1.2" currently resolves to nothing. There is no tag, no release, and no commit a third party can name without reading
version.txthistory.The v0.1.1 release commit deliberately decoupled the release version from the spec version, so
version.txtmoves on its own schedule while schema$idstays atv0.1.0. That decoupling is correct and it also removes the signal that used to make an untagged bump obvious.Impact on implementers
A second implementer writing a conformance claim cannot state which release they built against. The contributors filing conformance evidence today (#109, #111, #113) are reporting against a tree that has no citable version.
Worth deciding alongside #99, which asks how release-branch versioning works now that
sync_version.ymlfollowsintegration. A tagging rule and a branch rule are the same decision.Current Priority Scope
Feeds conformance evidence