Skip to content

Commit bebd79e

Browse files
committed
Add versioning approach documentation #2653
Signed-off-by: Philippe Ombredanne <[email protected]>
1 parent 3b813f0 commit bebd79e

File tree

2 files changed

+59
-0
lines changed

2 files changed

+59
-0
lines changed

docs/source/misc/index.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,3 +7,5 @@
77
faq
88
support
99
perf_report
10+
versioning
11+

docs/source/misc/versioning.rst

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
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

Comments
 (0)