Release: Versioning statement

[raghavkaul]

Is your feature request related to a problem? Please describe. Scorecard should issue a versioning statement.

Alternatives

Proposal 1: CalVer

• Releases can be scheduled in advance without worrying about what qualifies as major/minor
• Precedent: https://calver.org/#other-notable-projects
• This approach breaks consistency with previous scorecard releases

Proposal 2: SemVer

• Update the docs to issue a SemVer statemeng
  • E.g.: Any update to scoring triggers a major version release, any update to scoring that fixes a bug but doesn't change the algorithm triggers a minor version release.
• Would need to think about feature-flagging scoring changes by release (this is only partially implemented: https://github.com/ossf/scorecard/blob/4ebe521141260a4b308b2b709a43ddd201689c32/options/options.go#L201)

Scorecard API

With either versioning scheme, the Scorecard API should include in results:

• Commit SHA of Scorecard
• Version, if available

Scorecard-Action

Scorecard-Action should use the latest stable version of Scorecard.

[naveensrinivasan]

I completely agree that we need to come to an agreement on the versioning so that other projects are able to depend on and utilize scorecard as a library.

I support using SemVer, as other Projects are increasingly relying on our code base. Here are a few examples which are becoming essential.

1. https://github.com/guacsec/guac/issues/249
2. https://github.com/ossf/scorecard/issues/1683#issuecomment-1053626566

I would like to know what are issues/concerns in us maintaining sernver , if any.

[spencerschrock]

I think Go has standardized on SemVer, so at the end of the day it's whether we want that version to be:

• github.com/ossf/scorecard/v5
• github.com/ossf/scorecard/v2023.1.1 (or similar)

Personally, I prefer the former.

Update the docs to issue a SemVer statemeng E.g.: Any update to scoring triggers a major version release, any update to scoring that fixes a bug but doesn't change the algorithm triggers a minor version release.

I think this discussion gets easier with Structured results.

Major: Removal of a rule Minor: Addition of a rule Patch: Bug fix of a rule

There's still the discussion about whether a major scoring change (e.g. rule overhaul) is a Major or a Minor. Which I think can be done with the addition of a new rule for the new behavior, deprecation of the old rule, and then a removal at some point.

Would need to think about feature-flagging scoring changes by release (this is only partially implemented:

I was under the impression we were consolidating on just SCORECARD_EXPERIMENTAL to feature-flag.

API

With either versioning scheme, the Scorecard API should include in results:

Commit SHA of Scorecard Version, if available

This sounds like no change from the current behavior

Action

Scorecard-Action should use the latest stable version of Scorecard.

Again, no change from the current behavior

[github-actions[bot]]

Stale issue message - this issue will be closed in 7 days

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.