### example data provided by the CVE Program
```json
  "versions": [
    {
      "version": "1.0.0",
      "status": "affected",
      "lessThan": "1.0.6",
      "versionType": "semver"
    }
  ],
  "defaultStatus": "unaffected"
```
### algorithm provided by the CVE Program
```C
for entry in product.versions {
    if entry matches V {
        return status specified by entry for V
    }
}
return product.defaultStatus
```
### new proposals
* rename all fields
```json
  "versions": [
    {
      "inclusiveLowerBound": "1.0.0",
      "status": "affected",
      "exclusiveUpperBound": "1.0.6",
      "versionType": "semver-2.0.0"
    }
  ],
  "defaultStatus": "unaffected"
```
* rename `version`
```json
  "versions": [
    {
      "greaterThanOrEqual": "1.0.0",
      "status": "affected",
      "lessThan": "1.0.6",
      "versionType": "semver-2.0.0"
    }
  ],
  "defaultStatus": "unaffected"
```
* keep field names; change how unbounded ranges are expressed
```json
  "versions": [
    {
      "version": "1.0.0",
      "status": "affected",
      "lessThan": "0.0.0-0",
      "versionType": "semver-2.0.0"
    }
  ],
  "defaultStatus": "unaffected"
```
### Hypothesis 1
* consumer's codebase pays no attention to `semver-2.0.0`
* Natural Sort Order is used for numbers such as 1.0.0 and 1.0.6
* `if entry matches V` is always false
* outcome is always `unaffected`
### Hypothesis 2
* consumer's codebase does not programmatically process an unknown string like `semver-2.0.0`
* if consumer had no advance notice, ingest of CVE Record version data is delayed
### Hypothesis 3
* producer adoption will be very slow
* consumer codebase updates will be relatively fast
* number of records with false `unaffected` outcome or delay will be minimal
### Hypothesis 4
* consumer codebases are largely unsuccessful at programmatically processing today
* new risks of false results aren't much different from today's risks of false results
* consumers want well-formed data to have a different `type` label than legacy malformed data