|
| 1 | +.. versioning: |
| 2 | +
|
| 3 | +
|
| 4 | +Versioning approach |
| 5 | +========================== |
| 6 | + |
| 7 | +ScanCode is composed of code and data (mostly license data used for license |
| 8 | +detection). In the past, we have tried using calver for code versioning to also |
| 9 | +convey that the data contained in ScanCode was updated but it proved to be not |
| 10 | +as clear and as effective as planned so we are switching back to semver which is |
| 11 | +simpler and overall more useful for users. We also want to provide hints about |
| 12 | +JSON output data format changes. |
| 13 | + |
| 14 | +Therefore, this is our versioning approach starting with version 30.0.0: |
| 15 | + |
| 16 | +- ScanCode releases are versioned using semver as documented at |
| 17 | + https://semver.org using major.minor.patch versioning. |
| 18 | + |
| 19 | +- Significant changes to the data (license or copyright detection) is considered |
| 20 | + a major version change even if there are no code changes. The rationale is |
| 21 | + that in our case the data has the same impact as the code. Using outdated data |
| 22 | + is like using old code and means that several licenses may not be detected |
| 23 | + correctly. Any data change triggers at least a minor version change. |
| 24 | + |
| 25 | +- We will signal separately to users with warnings messages when ScanCode needs |
| 26 | + to be upgraded because its data and/or code are out of date. |
| 27 | + |
| 28 | + |
| 29 | +In addition to the main code version, we also maintain a secondary output data |
| 30 | +format version using also semver with two segments. The versioning approach is |
| 31 | +adapted for data this way: |
| 32 | + |
| 33 | +- The first segment --the major version-- is incremented when data attributes |
| 34 | + that are removed, renamed, changed or moved (but not reordered) in the JSON |
| 35 | + output. Reordering the attributes of a JSON object is not considered as a |
| 36 | + change and does not trigger a version change. |
| 37 | + |
| 38 | +- The second segment --the minor version-- of the output format is incremented |
| 39 | + for an addition of attributes to the JSON output. |
| 40 | + |
| 41 | +- We store the output format version string in the JSON output object as the |
| 42 | + first attribute and display that also in the help. |
| 43 | + |
| 44 | +- This output format versioning applies only to the JSON, pretty-printed JSON, |
| 45 | + YAML and JSON lines formats. It does not apply to CSV and any other formats. |
| 46 | + For these other formats there is no versioning and guaranteed format stability |
| 47 | + (or there may be some other rationale and convention for versioning like for |
| 48 | + SPDX). |
| 49 | + |
| 50 | +- The output format version is incremented by when a new ScanCode tagged release |
| 51 | + is published |
| 52 | + |
| 53 | +- We document in the CHANGELOG the output format changes in any new format version. |
| 54 | + |
| 55 | +- For any format version changes, we will provide a documentation on the format |
| 56 | + and its updates using JSON examples and a comprehensive and updated data |
| 57 | + dictionary. See https://github.com/nexB/scancode-toolkit/issues/2008 for details. |
0 commit comments