Open Dyanngg opened 6 months ago
@Dyanngg https://github.com/golang/go/issues/42312#issuecomment-720014209 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
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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Describe the issue: It has been brought to my attention that the source code in go module
network-policy-api@v0.1.1
downloaded with thego 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/network-policy-api@v0.1.1 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: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.