-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional field for license list version #181
Comments
@goneall That works for me. Agree with keeping 2.x-compatible version (X.Y) with the current name so as not to break existing tooling. For the 3.0 version (X.Y.Z), I'm fine with In practice, I don't expect we will regularly if ever issue a release of the license list that isn't X.Y.0. (Unless you tell me that we'll need to issue 3.24.1 to fix this current issue...) :) |
+! for Steve, during the tech call I said that I don't know of any updated release process for the license list, but I assume that, if the list changes (new licenses are added) this will be at least a minor update (changing the Y part in X.Y.Z). Conversely, I can think of a patch update (going to x.y.1 and beyond) only for minor tweaks like metadata of licenses, or update of XML expressions. Although I doubt anything would be so urgent that would necessitate a patch update and not waiting till the next minor one. |
On the 28 May 2024 tech call, we discussed an issue where the SPDX 2.X documents created with the latest license list is failing validation due to the addition of the patch version (which is required for SPDX 3.0 validation).
To solve this, it was suggested we have 2 different SPDX version properties - one that is compatible with SPDX 2.X and one that is compatible with SPDX 3.
This could be generated automatically in the license list publisher by stripping off the patch version for the compatible version.
The text was updated successfully, but these errors were encountered: