Is it too late to rename CacheCapabilities.blob_splice_support to splice_blob_support, to match the SpliceBlob rpc name?

[mostynb]

Protobuf creates a CacheCapabilities.BlobSpliceSupport field, which is (slightly) annoyingly differently named to the SpliceBlob rpc call name. Is it too late to rename CacheCapabilities.blob_splice_support to CacheCapabilities.splice_blob_support ? And similarly for CacheCapabilities.blob_split_support of course.

Does renaming fields, but keeping the semtantics break clients?

[ukai]

protocol buffer's wire format depends on tag number, not field name, so we could rename field without breaking backward compatibility ?
https://protobuf.dev/best-practices/dos-donts/

[sluongng]

It is worth noting that we have yet to cut an official release with Split/Splice API, so I think all the current changes can be counted as "unstable" and therefore, amendable.

In terms of breakages, we are not only accounting for the protobuf definition, but also the Go SDK generated and checked into the repo. And such a rename will be a breakage for the GoSDK.

I still think it's ok to change it. But we should consolidate all the amendments and cut a release to mark the feature as "stable" soon.

cc: @roloffs

[mostynb]

Here's a PR to make this change: #340

[roloffs]

From our side, changing the names of these fields is fine. Although, we already have a release of our build tool using the old names, we are mainly interested in that the wire format (numbering of the fields) remains the same and this is the case, so that is good to go from our side.