search

p4lang / p4runtime

Specification documents for the P4Runtime control-plane API
Apache License 2.0
144 stars 88 forks source link

Version 1.4.0 rc updates to bazel and protobuf comments #499

Closed chrispsommers closed 2 weeks ago

chrispsommers commented 3 weeks ago

Merge accumulated 1.4.0 updates by consensus in WG mtg:

smolkaj commented 3 weeks ago

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

antoninbas commented 3 weeks ago

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 f50fef914398498fa97434b4b0183a6b5f74fc3f). 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 f50fef914398498fa97434b4b0183a6b5f74fc3f 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.

smolkaj commented 3 weeks ago

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 :)

antoninbas commented 3 weeks ago

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.

smolkaj commented 3 weeks ago

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