Include any version system that allows meaningful ordering for the consumer

[sthagen]

The current schema contains a restriction on the semantics of version identifiers that is not refelcted in the pattern and IMO is not beneficial to the producers and consumers.

"version_t": {
    "title": "Version",
    "description": "[...] Format must be understood as 'major.minor.patch.build' version.",
    "type": "string",
    "pattern": "^(0|[1-9][0-9]*)(\\.(0|[1-9][0-9]*)){0,3}$"

Proposal:

Rewrite description above text value as:

"[...] Format must be interpretable as 'major[.minor[.patch[.build]]]' version, calendar version, or any other simple sequential numbering scheme."

or similarly.

Rationale:

Any calendar version matches the ordering expectation within the security advisories sharing community.

[santosomar]

This is a good suggestion and provides good guidance.

[tolim]

It is important that CSAF parsers are able to determine the order of advisory releases (i.e. which is the latest one?). In your suggestion you include or any other simple sequential numbering scheme. How do we ensure that used algorithms will work correctly here as well?

So I propose to change the description of version_t as follows:

"[...] Format must be interpretable as 'major[.minor[.patch[.build]]]' version. Alternatively, a calendar version or any other simple sequential numbering scheme may be used that allows ASCII sorting in the order of the document releases."

A small side note: In revision_history, we also require the property date that allows to determine this order:

            "revision_history": {
              "type": "array",
              "minItems": 1,
              "items": {
                "type": "object",
                "properties": {
                  "number": {
                    "$ref": "#/definitions/version_t"
                  },
                  "date": {
                    "title": "Date of the revision",
                    "description": "The date of the revision entry",
                    "type": "string",
                    "format": "date-time"
                  },
                  "description": {
                    "type": "string"
                  }
                },
                "required": [
                  "number",
                  "date",
                  "description"
                ]
              }
            },

However, if two releases are published on the same day, we will have a problem once again. We might require people to also specify the time of the revision, but this is not needed if we provide a clear way how to sort the versions.

[tschmidtb51]

I agree on the first part. The documentation should be changed to:

"[...] Format must be interpretable as 'major[.minor[.patch[.build]]]' version.

However, at the moment I fail to see where the problem with this restriction for the consumers or producer is. Most of the latter will already use a numbering system. The date is already included in the revision_history.

@tolim : I guess, the current system is not ASCII-sortable but that is a good point.

[tschmidtb51]

121 is a pull request which also changes the description to reflect the restriction on the semantics of version identifiers in the pattern.

[sthagen]

The point was here, that vendors issuing calendar based versioning might want to also use calender versioning on their SAs. There is no problem of releasing an updated SA every second or millisecod, as my proposed text just removed the unnecessary constraint of the semantic versioning "terms".

"Major and friends" convey a semantic segmentation which is IMO more often than not (and especially in SAs) only distracting.

Just imagine issuing an SA and have to answer the questions:

• What is a minor update of an SA anyway?
• ... what is a patch?
• ... do we even need reproducible builds for SAs 😉 ...

I imagine in such cases to just use serial incrementing (single integer) versioning or calendar versioning. But, issuing a 4.1.2.444 following a 4.1.1.99999 (because intermediate internal versions of the SA failed some tests at least 443 times)? Defending why it is not a 4.2... or 5.0...? No, not really.

I remember when we designed CVRF 1.2 we had to face a reality of SAs without any meaningfully parseable date information and also "interesting" version identifiers.

[tschmidtb51]

I would suggest to close the issue in favor of the discussion in #214 and the related PR #233.