[aurangzaib048]

What was wrong
SPDX_SCHEMAS is keyed by exact version, so a 3.0.2 document matched no schema and was refused as unsupported. The sbomify backend checks the same document against the 3.0.1 schema and accepts it. The upload tool refused a document the upload endpoint takes.

The fix
A 3.0 patch above the newest bundled one uses the 3.0.1 schema, unchanged, as the backend does. The schema's @context pin stays on the 3.0.1 URL, so a 3.0.2 document that keeps the 3.0.1 context passes, and one that declares a 3.0.2 context is refused on both ends. The SPEC_VERSION hint offers SBOM_FILE for such a version too.

Verified
A 3.0.2 document with the 3.0.1 context validates, which is what the backend's own 3.0.2 test sends. A 3.0.2 context is refused with a schema error, not "not supported", and a schema violation still fails. The acceptance test fails on master.

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

Review effort: Lite
Findings: 2

Open (2)

• _NEWEST_SPDX30 hard-codes the newest bundled 3.0.x schema version, which can drift when schemas… · New
• Indexing SPDX_SCHEMAS[schema_version] can raise KeyError if spdx_schema_version() ever… · New

What changed in this PR

Aligns SPDX 3.0.x patch handling with the sbomify backend so newer 3.0 patch documents (e.g., 3.0.2) validate against the newest bundled 3.0 schema instead of being rejected as “unsupported”.

Changes:

• Add SPDX schema version resolution to map later 3.0 patch spec versions to the bundled 3.0.1 schema.
• Update CLI hinting so later 3.0 patches are offered SBOM_FILE guidance.
• Add/adjust tests and documentation to cover/describe later SPDX 3.0 patch acceptance behavior.

File	Description
sbomify_action/​validation.py	Introduces spdx_schema_version() and uses it to pick a schema for later SPDX 3.0 patch versions.
sbomify_action/​cli/​main.py	Uses schema resolution logic to decide whether to offer SBOM_FILE for SPDX 3.x versions.
tests/​test_validation.py	Adds acceptance tests for SPDX 3.0.2 held to the 3.0.1 schema/context rules.
tests/​test_config.py	Ensures CLI error text offers SBOM_FILE guidance for SPDX 3.0.2.
README.md	Documents that SPDX 3.0.1 and later 3.0 patches are accepted for JSON-LD uploads.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

User-facing docs and CLI hints should explicitly mention the pinned @context requirement for later SPDX 3.0.x patches to avoid misleading users into thinking any 3.0.2 document will validate.

Review effort: Lite
Findings: 1 · 2

Open (3)

• Error hint omits pinned @​context requirement for patch versions · New
• README overstates later 3.0 patch support without context pin · New
• Hard-coded context comment will drift as bundled schemas change · New

Resolved since last review (2)

• Indexing SPDX_SCHEMAS[schema_version] can raise KeyError if spdx_schema_version() ever…
• _NEWEST_SPDX30 hard-codes the newest bundled 3.0.x schema version, which can drift when schemas…

[Copilot]

🟢 Approval recommended

The SPDX 3.0 patch schema-mapping behavior is implemented consistently across validation and CLI messaging, with targeted tests and documentation updates covering the intended acceptance rules.

0 open findings

3 resolved since last review

• Error hint omits pinned @​context requirement for patch versions
• Hard-coded context comment will drift as bundled schemas change
• README overstates later 3.0 patch support without context pin

🧠 Review effort: Lite

[aurangzaib048]

@vpetersson-bot could you review this one? Copilot has no open findings on the current head and CI is green.

[vpetersson-bot]

@aurangzaib048 this looks correct to me. Approving.

What I checked on c0d54aa:

• spdx_schema_version maps 3.0.0 and 3.0.1 to themselves, any 3.0.N with N >= 1 to the newest bundled 3.0 schema, and returns None for 3.0.02, 3.0.2-rc1, 3.1 and whitespace-padded input. _NEWEST_SPDX30 comes from the registry, so bundling 3.0.2 later moves it without any further edits.
• A 3.0.2 document that keeps the 3.0.1 @context validates. If you parse it with parse_spdx3_file and write it back out with write_spdx3_file, which is the augmentation path, it keeps the 3.0.1 context and specVersion: 3.0.2 and still validates. So augmenting it doesn't break validation further down.
• The new acceptance tests in tests/test_validation.py and tests/test_config.py fail when I run them against master's sbomify_action/, and they pass on this branch.
• Locally, ruff check, ruff format --check and mypy are clean, and the validation, config and schema-compliance tests pass (166). On the full suite, 3889 pass. Three fail, and none of them comes from this PR: two uv build tests in test_tool_manifest.py hit a problem with my host's uv setup, and test_generate_uses_first_matching_generator needs cdxgen/syft, which I don't have installed. That last one fails on master too.

Two non-blocking nits:

1. sbomify_action/validation.py:307: the success log says "validated successfully against SPDX 3.0.2 schema", but the schema actually used was 3.0.1. Logging the resolved schema version, e.g. "SPDX 3.0.2 (3.0.1 schema)", would be more accurate when someone is debugging a context-pin failure.
2. tests/test_validation.py:481: result.error_message or "" would also pass if the result were skipped (valid is None). Adding self.assertIs(result.valid, False) would make the test confirm the document got as far as schema validation.

The branch is 2 commits behind master (the urllib3 bump), and GitHub reports it as mergeable.