Clarify and relax requirements on tool.semanticVersion

The spec currently says the following about tool.semanticVersion:
3.12.4     semanticVersion property
In a log file produced by an analysis tool, a tool object SHALL contain a property named semanticVersion whose value is a string containing the tool version in the format specified by [SEMVER].

 

There are two problems.

 

The wording “a string in the format specified by [SEMVER]” is too loose. It made people think that any three-component version number like “3.2.1” qualifies as a SemVer, whereas in fact SemVer carefully defines the semantics of each of those three components. The intent of SemVer is that you can look at any two version numbers and tell whether there are breaking changes between them.

I would change this to clarify that if you populate semanticVersion, then you must conform in syntax and semantics to SemVer.

 

When I wrote the words “a tool object SHALL contain a property named semanticVersion”, I really did mean to say to tool vendors: “You want to use SARIF? Then get on board with SemVer!”. But I regret that now. You just can’t ask tool vendors to change their versioning strategy just to use a wonderful new output format. I’d like to change that to SHOULD.

I propose the following, to address both issues:

 

In a log file produced by an analysis tool, a tool object SHOULD contain a property named semanticVersion whose value is a string that SHALL conform to the syntax and semantics of [SEMVER].

 

I took some pains over the wording. I want to convey that you don’t have to supply it, but if you do, it needs to be a real SemVer.

 

Thoughts? If we agree, I’ll file a CSD.1 issue and fix it.

Larry