[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] Clarify and relax requirements on tool.semanticVersion
When I think of SemVer, I see two clear values. 1) the version information is sortable, providing a (presumably) chronological ordering of tool versions, 2) it provides semantics for breaking changes in tools. Can you articulate why you believe these values are critical to put in a SARIF file? How will a consumer make use of it? Have I missed other key values in your estimation? At this point, I don’t have clear line of sight into why this is a SHOULD (and not a MAY or emitted from the standard altogether). Can you help make the case again? From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast) 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.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]