Merge branch 'development/v3.0.1' into add-chap-conformance

CHANGELOG.md

@@ -1,11 +1,16 @@
 # Change Log
+
 All notable changes to this project will be documented in this file.
 
-## 3.0
+## 3.0 (2024-04-15)
+
+See the v3.0 GitHub release notes for changes
+[in the spec](https://github.com/spdx/spdx-spec/releases/tag/v3.0) and
+[in the model](https://github.com/spdx/spdx-3-model/releases/tag/3.0).
 
-See the [v3.0 GitHub release notes](https://github.com/spdx/spdx-spec/releases/tag/v3.0) for changes.
+See also the [SPDX specification 3.0 release announcement](https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases)
 
-## 2.3
+## 2.3 (2022-11-03)
 
 See the [v2.3 GitHub release notes](https://github.com/spdx/spdx-spec/releases/tag/v2.3) for changes.
 

CONTRIBUTING.md

@@ -1,44 +1,83 @@
 # Contributing
 
-The SPDX specification is maintained by the SPDX [legal][spdx-legal] and [tech][spdx-tech] teams.
-Design and planning is primarily done via the team [mailing][spdx-legal-list] [lists][spdx-tech-list] and meetings.
+The SPDX specification is maintained by the SPDX [legal][spdx-legal] and
+[tech][spdx-tech] teams.
+Design and planning is primarily done via the team [mailing][spdx-legal-list]
+[lists][spdx-tech-list] and [meetings][meetings].
 
 ## Contribution License Agreement
 
-Contributions to this repo are made pursuant to the [SPDX Community Specification Contributor License Agreement 1.0][cla]. You do not need to submit a signed copy of the contributor license agreement; by making a contribution to this repo, you agree to the terms set forth in that agreement.
+Contributions to this repo are made pursuant to the
+[SPDX Community Specification Contributor License Agreement 1.0][cla]. You do
+not need to submit a signed copy of the contributor license agreement; by
+making a contribution to this repo, you agree to the terms set forth in that
+agreement.
 
 ## Submitting changes
 
-Always write a clear log message for your commits. One-line messages are fine for small changes, but significant changes should look like this:
+Always write a clear log message for your commits. One-line messages are fine
+for small changes, but significant changes should look like this:
 
-    $ git commit -m "Subject of the commit
-    > 
-    > A paragraph describing what changed and its impact."
+```shell
+$ git commit -m "Subject of the commit
+>
+> A paragraph describing what changed and its impact.
+>
+> Signed-off-by: Contributor Name <name@example.com>"
+```
 
-A properly formed Git commit subject line should always be able to complete the following sentence: if applied, this commit will "Subject of the commit". For example :
+Every commit message also needs a sign-off line, or it will not pass a test in
+the workflow. This line starts with `Signed-off-by:` and specifies the name and
+the email address of the person who submitted the changes. You can also use the
+`-s` or `--signoff` option with `git commit` to automatically append the line
+to your commit message (it will use `user.name` and `user.email` from your
+`.git/config` configuration file).
 
-    if applied, this commit will Add chapter on Security Vunerabilities in SPDX
-    if applied, this commit will Delete section with deprecated SPDX attributes 
-    if applied, this commit will Fix grammar in Package Version field description
+A properly formed Git commit subject line should always be able to complete the
+following sentence: if applied, this commit will "Subject of the commit".
 
-Git itself uses this approach. When you merge something it will generate a commit message like "Merge branch...", or when reverting "Revert...".
+For example :
+
+```text
+if applied, this commit will Add chapter on Security Vunerabilities in SPDX
+if applied, this commit will Delete section with deprecated SPDX attributes 
+if applied, this commit will Fix grammar in Package Version field description
+```
+
+Git itself uses this approach. When you merge something it will generate a
+commit message like "Merge branch...", or when reverting "Revert...".
 
 ### Minor Changes
-Minor changes such as markup and typo fixes may be submitted directly to this repository (either as [issues][] or [pull-requests][]) without previous discussion.
-Please submit all minor changes against the `development/v2.3` branch which is the current version of the SPDX specification.
+
+Minor changes such as markup and typo fixes may be submitted directly to this
+repository (either as [issues][] or [pull-requests][]) without previous
+discussion.
+
+Please submit all minor changes against the `development/v3.0.1` branch which
+is the current development version of the SPDX specification.
 
 ### Major Changes
-Any change that break backwards compatibility or requires significant tooling changes is considered a major change.
-You may want to discuss major changes on the mailing list first to get design feedback before investing time in a pull request.
-Please submit all major changes against the `development/v3.0` which is the next major version of the specification. 
+
+Any change that break backwards compatibility or requires significant tooling
+changes is considered a major change.
+You may want to discuss major changes on the mailing list first to get design
+feedback before investing time in a pull request.
+
+Please submit all major changes against the `development/v3.1` which is the
+next major version of the specification.
 
 ### Target Milestones
-When submitting an issue or pull request, please add a suggested release milestone.  This will ensure the issue or pull request is reviewed for inclusion in that release.
 
-If your issue or pull request is independent of a release, you can use the `release-independent` milestone.
+When submitting an issue or pull request, please add a suggested release
+milestone. This will ensure the issue or pull request is reviewed for inclusion
+in that release.
+
+If your issue or pull request is independent of a release, you can use the
+`release-independent` milestone.
 
 [cla]: https://github.com/spdx/governance/blob/main/0._SPDX_Contributor_License_Agreement.md
 [issues]: https://github.com/spdx/spdx-spec/issues/
+[meetings]: https://github.com/spdx/meetings/
 [pull-requests]: https://github.com/spdx/spdx-spec/pulls/
 [spdx-legal]: https://wiki.spdx.org/view/Legal_Team
 [spdx-legal-list]: https://lists.spdx.org/mailman/listinfo/spdx-legal

docs/annexes/diffs-from-previous-editions.md

@@ -2,6 +2,12 @@
 
 ## A.1 Differences between V3.0 and V2.3 <a name="A.1"></a>
 
+### SPDX meaning
+
+In previous editions of the specification, SPDX meant "Software Package Data Exchange".
+
+Starting with V3.0, the scope of SPDX has expanded beyond software and now means "System Package Data Exchange".
+
 ### Structural Differences
 
 These are the most significant breaking changes requiring a change in logic to handle a different model or structure for the information.  Each structural difference will describe the change, describe an approach to translate from 2.3 to 3.0, and provide a rationale for the change.