📖 Add pkg.go.dev badge and update package versions

[naveensrinivasan]

What kind of change does this PR introduce?

Doc update

• PR title follows the guidelines defined in our pull request documentation

What is the current behavior?

What is the new behavior (if this is a feature change)?**

• Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

NONE

Special notes for your reviewer

Does this PR introduce a user-facing change?

NONE

[codecov]

Codecov Report

Merging #1680 (b694460) into main (7956ff4) will increase coverage by 3.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1680      +/-   ##
==========================================
+ Coverage   57.45%   60.58%   +3.13%     
==========================================
  Files          58       58              
  Lines        5907     5907              
==========================================
+ Hits         3394     3579     +185     
+ Misses       2276     2085     -191     
- Partials      237      243       +6     

[github-actions]

Integration tests success for
[0327195]
(https://github.com/ossf/scorecard/actions/runs/1904016129)

[github-actions]

Integration tests success for
[19374a9]
(https://github.com/ossf/scorecard/actions/runs/1904861495)

[azeemshaikh38]

I'm concerned about directing users here while we don't officially yet support Scorecard as a library. Apart from the LGTM.

[naveensrinivasan]

I'm concerned about directing users here while we don't officially yet support Scorecard as a library. Apart from the LGTM.

I think we should start supporting it. There are projects using it.

• Scorecard-actions (this is WIP)
• Witness
• Allstar

We should document that we don't support Semver but scorecard/v4 similar to Go GitHub Libary.

Thoughts? @azeemshaikh38 @laurentsimon @justaugustus

[justaugustus]

Adding code suggestions on package version and pkg.go.dev URL.

[github-actions]

Integration tests success for
[b694460]
(https://github.com/ossf/scorecard/actions/runs/1906416969)

[justaugustus]

I'm concerned about directing users here while we don't officially yet support Scorecard as a library. Apart from the LGTM.

I think we should start supporting it. There are projects using it.

This presentation is worth a look: https://dave.cheney.net/practical-go/presentations/gophercon-israel.html#apidesign

Of note:

If it’s exported, its part of your public API.

That said, we have a responsibility to design APIs that are hard to misuse.

* Scorecard-actions (this is WIP)

ossf/scorecard-action#107 (cc: @rohankh532)

* Witness

#1673 / #1245 / #1682 (cc: @colek42)

* Allstar

#1645 / ossf/allstar#114

#1645 just merged, which makes some decent steps in the right direction and I'll open a separate tracking issue for this if one doesn't already exist.

We should document that we don't support Semver but scorecard/v4 similar to Go GitHub Libary.

Disagree here and I've expressed the opinion in a few places, including the most recent (2022-02-24) biweekly meeting.

We've adopted SemVer-compliant versioning, which means regardless if we've enforce SemVer or not, consumers will have at least a baseline expectation that we are compliant. Whether that is true or not is a different story.

I think we should instead declare that the next major release version (v5.0.0) is the first release in which we will be SemVer-compliant and direct our efforts into designing the module in a way that we can ensure that.

I think we'll all agree that scorecard is a high-value project in a space with lots of eyes on it today, so we have a responsibility to those who consume it to make it as easy and clear to do so as possible.

[justaugustus]

I think we should instead declare that the next major release version (v5.0.0) is the first release in which we will be SemVer-compliant and direct our efforts into designing the module in a way that we can ensure that.

I've created a tracking issue for this and added it to the v5 milestone: #1683
Let's continue the discussion there!

[naveensrinivasan]

I'm concerned about directing users here while we don't officially yet support Scorecard as a library. Apart from the LGTM.

I think we should start supporting it. There are projects using it.

This presentation is worth a look: https://dave.cheney.net/practical-go/presentations/gophercon-israel.html#apidesign

Of note:

If it’s exported, its part of your public API.

That said, we have a responsibility to design APIs that are hard to misuse.

* Scorecard-actions (this is WIP)

ossf/scorecard-action#107 (cc: @rohankh532)

* Witness

#1673 / #1245 / #1682 (cc: @colek42)

* Allstar

#1645 / ossf/allstar#114

#1645 just merged, which makes some decent steps in the right direction and I'll open a separate tracking issue for this if one doesn't already exist.

We should document that we don't support Semver but scorecard/v4 similar to Go GitHub Libary.

Disagree here and I've expressed the opinion in a few places, including the most recent (2022-02-24) biweekly meeting.

We've adopted SemVer-compliant versioning, which means regardless if we've enforce SemVer or not, consumers will have at least a baseline expectation that we are compliant. Whether that is true or not is a different story.

I think we should instead declare that the next major release version (v5.0.0) is the first release in which we will be SemVer-compliant and direct our efforts into designing the module in a way that we can ensure that.

I think we'll all agree that scorecard is a high-value project in a space with lots of eyes on it today, so we have a responsibility to those who consume it to make it as easy and clear to do so as possible.

I agree. Thanks for the details.

I will wait for @azeemshaikh38 before I merge.

[justaugustus]

I will wait for @azeemshaikh38 before I merge.

I agree that the API is a longer discussion, but I don't think we need to block the badge updates on it.

[naveensrinivasan]

I will wait for @azeemshaikh38 before I merge.

I agree that the API is a longer discussion, but I don't think we need to block the badge updates on it.

Sounds good. 👍