Does this make sbom-tool Generate -ManifestInfo SPDX:2.2 an error and require SPDX:2.2.2 instead? If so, that's a breaking change and I hope it will be well documented. It should then be changed here too:

Currently, Microsoft.Sbom.Targets 3.0.0 places the SBOM at _manifest/spdx_2.2/manifest.spdx.json within the generated NuGet package. In the future, as the SBOM tool is updated for subsequent versions of SPDX, are consumers of NuGet packages expected to enumerate the subdirectories of _manifest rather than assume this path?

@KalleOlaviNiemitalo I assume and expect that this command

sbom-tool Generate -ManifestInfo SPDX:2.2

will just generate an SBOM with SBOMSpecification("SPDX", "2.2.2") (and any 2.2.x, as a feature-compatible version of 2.2), using spdx_2.2 folder.

But, yes, if it is an error, it will be definitely a breaking change - which is not desired and we need a way support BOTH 2.2 and 2.2.2 at the same time down to the command-line (because scripts/workflow will rely on it).

@KalleOlaviNiemitalo and @bact, we're discussing this internally to determine our best path forward. We have internal validation tooling that expects the spdx_2.2 folder, so that will break if we suddenly change the folder name to spdx_2.2.2 We haven't yet determined exactly how we want to proceed to provide the optimal experience.

@THEJRRR is the person driving the requirements, so I'm adding him to the thread.

It's unlikely that we'll merge this PR. May I suggest moving the discussion to #738?

Please move the discussion over. Thank you.