[RELEASE] Released v0.1.1 gomodule source code and upstream v0.1.1 tag mismatch

[Dyanngg]

Describe the issue:
It has been brought to my attention that the source code in go module [email protected] downloaded with the go get command actually does not match the source code state in upstream v0.1.1 tag.

Specifically, according to https://pkg.go.dev/sigs.k8s.io/[email protected] the version was cut on Jul 3 2023, whereas from https://github.com/kubernetes-sigs/network-policy-api/commits/v0.1.1/ it was actually released on Aug 17. As a result, any source code / deliverables downloaded by user with the normal workflow (go.mod require or go get) for v0.1.1 will not include the change set from Jul 4 to Aug 17. If we clear all go cache and force go get to not use GOPROXY, it will try to download v0.1.1 from this repo, which will trigger a security error because of checksum mismatch:

➜  go get -u sigs.k8s.io/[email protected]
go: sigs.k8s.io/[email protected]: verifying go.mod: checksum mismatch
	downloaded: h1:h1mNosX5xtAXEYKkhcf3/M+IXMG80jqUHiPn8UnZno8=
	sum.golang.org: h1:F7S5fsb7QEzlLjuMgTGfUT4LRHylRbx2xDDpHfJKKEs=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

Suggestions:
A new release should be cut with tag v0.1.6 and marked as the latest release. After this, we should figure out how to resolve the discrepancy for v0.1.1 release.

[astoycos]

@Dyanngg golang/go#42312 (comment) Unfortunately there is no way to bump the tag commit within go modules :/

Really what we are intending to do is to cut an official v0.2.0 release as soon as the FQDN feature gets merged, In the meantime we could cut a v0.1.5 patch release just to get us past this ^^^ OR just rely on the v0.1.5 tag for now

[tssurya]

yeah as spoken in the meeting, let's cut the 0.1.5 release and then do another one for fdqn at 0.1.6 -> its easy to digest features that way

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten