6.0.0 Planning: Clean Up and a SemVer Commitment

[alilleybrinker]

I believe the QWG should pursue releasing version 6.0.0 by Q1 2026, with three parts in scope for the release:

• Adopting the new semver-2.0.0 type with additional fields to support expressing unbounded ranges
  • Add a formal semver 2.0.0 version type #371
• Adopting SemVer for versioning the Record Format and committing to API stability guarantees going forward
  • Develop a CVE Record Format Versioning RFD #418
• Fixing open bugs in the Record Format
  • https://github.com/CVEProject/cve-schema/issues?q=state:open%20label:bug

This would be a "small" release, but would achieve several key goals:

• Introducing the highly-desirable semver-2.0.0 version type
• Giving clear guarantees for all CVE stakeholders about stability going forward
• Tightening up data validation by fixing open bugs

While there are ideas for larger redesigns of parts of the Record Format floating around the QWG, no formal proposals to do so have been advanced, nor even workshopped in rough forms at this stage. We should not delay 6.0.0 while waiting for these redesigns to materialize and be debated.

Instead, we should aggressively pursue a near-term 6.0.0 which tightens up the format and commits to clear API versioning guarantees, and then work on larger redesigns throughout the 6.0.0 lifecycle via the RFD process, to be made in a future 7.0.0.

---

After further thinking, here's a rough list of things which could be candidates for 6.0.0, along with statuses for what needs to happen to get them to the "Ready to Merge" state:

Candidates for version 6.0.0 of the CVE Record Format

The following are candidate improvements to the CVE Record Format which could
in theory be included in version 6.0.0. Not all of these are breaking, but
many are, and others are included to give stakeholders in CVE motivation to
upgrade to newer versions.

Topic	Status
CVE Record Format validation library	Needs RFD
Structured way to represent remediation	Needs RFD
CNA organization type	Needs RFD
affectedArtifacts	Needs Review
semver-2.0.0 version type and new version fields	Needs Review
Require repo field for "git" version type	Ready to Merge
Require .cveMetadata.datePublished and cveMetadata.dateUpdated	Ready to Merge
Complete the incomplete "source" field in adpContainer and adpPublishedContainer	Ready to Merge
Correct data types in .containers.cna.source.defect	Ready to Merge
Enforce UTC and timezones	Ready to Merge
Support for SSVC	Ready to Merge

Statuses:

• Needs RFD: Needs to have an RFD written.
• Needs Review: Has an RFD, needs to be reviewed and accepted.
• Needs User Study: Has an RFD, needs a User Study with the CWG.
• Ready to Merge: Has a Pull Request which is ready to merge.

[darakian]

Can we define what we mean by Q1? Is this The January to March 2026 time frame? I ask because microsoft (and potentially others) use the quarterly system with an offset. As evidence microsoft just recently reported their q4 2025 earnings
https://www.microsoft.com/en-us/investor/earnings/fy-2025-q4/press-release-webcast
I'd rather this point not be ambiguous.

Additionally I'd like to ask the hard question out loud. If there's public commitment from the CVE program on delivering a 6.0.0 by date X what's the or else associated with that commitment?

[alilleybrinker]

First, I will say this is just my personal proposal at the moment and doesn't reflect a commitment by the CVE Program or MITRE or any other organization.

Second, by Q1 I mean between January and March. So the first quarter of the calendar year, 2026.

Finally, I'm not sure what sort of commitment you'd be looking for if this commitment did get made and the intended deadline was then missed.

[darakian]

Maybe that question is better asked as what does a commitment look like in hard terms?.

[alilleybrinker]

The commitment, as intended here, would be a commitment by the QWG to deliver 6.0.0 in this timeframe, intended to bind the group to keep the scope limited.

The reason I want to include timing in this proposal is because I want to avoid a situation where 6.0.0 becomes repeatedly delayed by scope creep. This is a limited-scope proposal, and I think the QWG publicly committing to a timeline would provide a good mechanism within the QWG to reject proposals to amend the 6.0.0 plan by increasing its scope.

As for "what happens if the QWG misses the deadline," I don't think there's much the QWG could do to force itself to put out a version if in fact the work necessary to do it is not completed. This is a self-binding commitment intended to help clarify the 6.0.0 process' goals.