Brainstorming for 0.4.0 roadmap

[swinslow]

0.3.0 isn't out yet, but will likely be pushed in the next few days. In the meantime, let's start brainstorming for what to include in 0.4.0!

Nothing here is certain to be included, but please feel free to comment with ideas for improvements that we could go after for 0.4.0.

Governance improvements

• Maintainers: I'd like to start bringing on additional maintainers with commit access, beyond just myself (@swinslow). Maintainers should include folks who have demonstrated a commitment to ongoing contributions / bug fixes for the SPDX Golang tools.
• OpenSSF Best Practices badge: We've started working our way towards satisfying the OpenSSF Best Practices criteria. I'd like to complete the base tier of requirements prior to the 0.4.0 release if possible.

Functional enhancements

• SPDX 2.3 support: Depending on timing for when the next version of the spec comes out, we might pick up 2.3 support. (See also comments on generics in "Refactoring" below.)
• Validation: There are a number of fields right now that aren't closely checked for validity. As just one example, I don't believe SPDX IDs are checked to confirm that they use only permitted characters; many of the fields are plain strings and are not checked for particular formatting; etc.
  • A validator should also take into account whether and how it is used in connection with a loader. For example, tvloader could be adjusted to take a parameter to optionally fail on parsing, if the parsed document is not strictly valid.
• License expression modeling and syntax: Relatedly, at present the licensing fields are just plain strings with no validation at all.
  • These should take into account the SPDX license expression model and syntax.
  • The tools should likely also include one or more lists of the SPDX License List identifiers, as part of identifying valid vs. invalid license expressions. Might need lists from multiple versions of the license list for full accuracy.
• Upgrading and downgrading documents: It could be useful to have a function that e.g. takes an SPDX-2.1 document (spdx.Document2_1) and converts it to an SPDX_2.2 document (spdx.Document2_2). Or vice versa, going the other direction.
  • This would likely require converting the various sub-elements to the new version.
  • Could also take a strict parameter to fail if the conversion can't be done with 100% fidelity. For example, if an SPDX-2.2 document has a field or value that would be invalid in SPDX-2.1, then if strict is true then the downgrade from 2.2 to 2.1 should fail. If strict is false, then the downgrade would silently (or with a warning) drop the invalid data.

CI improvements

• SBOMs for releases: see #118
• Expand tests for other OS's: see #117

Refactoring / Bug Fixes

• Generics: Golang 1.18 is out, and we've got generics now. Let's figure out if it's possible and worthwhile to convert the various redundant code for 2.1 and 2.2 (and 2.3 and...) over to more of a single API model that abstracts away the versions to some extent. Might be useful for downstream users, and might be very helpful in getting rid of duplicative code.
• Fix Snippets in tag-value documents: see #124
• Handle additional cryptographic hash algorithms: see #96
• Consider reworking model for 'SPDX Item': see #48. Might be more correct and closer to SPDX object model.
  • How disruptive would this be for existing users, if at all? If want to make this change, best to do it well before any 1.0.0 release.