How should specVersion evolve while the schema remains 0.0.0?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- json
- Domain
- documentation, testing-qa
Research direction
Start by comparing the written specification and embedded examples with examples/minimal.json, examples/with-retries.json, examples/comprehensive.json, and the normative conformance tests. Review the referenced Microsoft.Testing.Platform mapping files and the v1 roadmap. Done means documenting one authoritative specVersion value, a pre-1.0 bump policy, and an immutable revision or compatibility policy.
Written by the indexing model from the issue text.
Description
Producer context
Microsoft.Testing.Platform validates its CTRF mapping against the upstream specification and currently emits a hard-coded "specVersion": "0.0.0":
- https://github.com/microsoft/testfx/blob/main/src/Platform/Microsoft.Testing.Extensions.CtrfReport/CtrfReportEngine.cs#L6-L11
- https://github.com/microsoft/testfx/blob/main/src/Platform/Microsoft.Testing.Extensions.CtrfReport/CtrfReportEngine.JsonSerializer.cs#L59-L70
The current specification says:
- its version is
0.0.0and this corresponds directly tospecVersion; specVersionfollows SemVer;- producers must use the highest CTRF version they fully support;
- consumers should support PATCH changes within a MAJOR.MINOR version.
However, normative schema changes such as the identity model (PR #57, merged July 2026) and clarified retry history (PR #62, merged August 2026) were added while the specification and schema still identify themselves as 0.0.0. The specification header date is also still 2025-11-24. Discussion #30 asks about the v1 roadmap but has no answer.
Questions
- Does
0.0.0mean “the latest revision onmain”, or does it identify a fixed schema revision? - When a normative field or constraint is added before 1.0, should
specVersionreceive a PATCH/MINOR bump (for example0.0.1or0.1.0)? - If all pre-1.0 revisions intentionally remain
0.0.0, how can a producer truthfully identify which schema revision it fully supports, and how can a consumer select the matching validator? - Is there or will there be a tagged/released schema artifact, immutable schema URL, or separate revision identifier that producers should record?
- Until that exists, should producers pin a commit and still emit
0.0.0, or is there another recommended compatibility policy?
Why this matters
Two documents can both claim specVersion: 0.0.0 while conforming to materially different versions of the normative schema. MTP needs a stable contract for deciding when to update its mapping and tests, and CTRF consumers need a reliable way to interpret and validate reports. A brief pre-1.0 release/versioning policy would resolve this without requiring the project to commit to v1 immediately.
Additional conflicting version signals
The current repository also contains a stronger contradiction than the unchanged 0.0.0 header alone:
- the standalone examples (
examples/minimal.json,examples/with-retries.json, andexamples/comprehensive.json) currently emit"specVersion": "1.0.0"; - normative conformance tests also use
"specVersion": "1.0.0"; - the written specification and its embedded examples still identify the working draft as
0.0.0; - the roadmap still shows the v1 release as incomplete, and the repository has no tags or releases.
That leaves a producer unable to tell whether 1.0.0 is already the intended interoperable value, whether those examples are premature, or whether the specification header is stale. Clarifying the currently valid value would be especially helpful in addition to defining the future bump policy.
- Dominant language
- No language data
- Stars
- 97
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ctrf-io/ctrf
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
mozilla/bedrock#17413 · 1 reaction ·
Maintainers usually reply within 2 days
-
automated issue report
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 92/100
github/copilot-sdk#2804 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
drizzle-team/drizzle-orm#6418 ·
Maintainers usually reply within 4 days
-
automated issue report
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
lirantal/discoprint#31 ·
Maintainers usually reply within 1 day