FYI, started a "prerelease" for 1.4.0 so the URLs in the Bazel rules work: https://github.com/p4lang/p4runtime/releases/tag/v1.4.0

FYI, started a "prerelease" for 1.4.0 so the URLs in the Bazel rules work: https://github.com/p4lang/p4runtime/releases/tag/v1.4.0

@smolkaj Once you create a tag (in this case v1.4.0) in the Git upstream, you are never supposed to mutate that tag (i.e., mutate the commit referenced by that tag, which is currently f50fef9). That's pretty much a golden rule, and it can break things if you do (e.g., Go modules - it's very much a pain to repair properly and can only be done by releasing a new greater version). Did you mean to create that tag already? Marking the Github release as a "pre-release" doesn't make a difference here, because the tag is still created the same way.

If f50fef9 was the intended commit for the v1.4.0 tag all along, please ignore, but it doesn't seem to be the case, given the existence of this PR. The only way to fix it without breaking anything would be to leave the v1.4.0 tag alone now, and release v1.4.1 with all the necessary extra changes.

Thanks for catching that. IIUC, you are saying that tags should always be immutable?

Would simply deleting the tag again address your concerns? Presumably no one has started using it quite yet :)

Thanks for catching that. IIUC, you are saying that tags should always be immutable?

Would simply deleting the tag again address your concerns? Presumably no one has started using it quite yet :)

No deleting the tag doesn't work.
The tag would already have been cache by https://proxy.golang.org/ (presumably right after you created it). See how it is already in the Go documentation: https://pkg.go.dev/github.com/p4lang/p4runtime?tab=versions
Mutating the tag, deleting the tag, deleting the tag in order to recreate it later (which is essentially the same as mutating it) can all create issues for downstream modules (again in the case of Golang) because of conflicts with https://sum.golang.org/
Even outside of Golang specifically, mutating a tag can create issues for software that depends on the project. Some processes which observe a tag that has changed, or release assets that have changed, can fail as it gets reported as a supply chain attack.
The only solution is to move on to v1.4.1 without changing v1.4.0.

Thanks for elaborating, Antonin, I was not aware of that.
SG regarding moving to v1.4.1.