Should we make a resolution to NOT have a v3?

[sluongng]

It seems like Remote API V2 has been getting a lot more traction since 2018.
Together with it is a wide list of build tools servers and vendors, https://github.com/bazelbuild/remote-apis?tab=readme-ov-file#api-users, adopting the specifications.

Given the recent industry lessons from Golang V2 (or the lack thereof) and Nix Flakes, and the good old Hyrum's Laws;
In combination with how https://github.com/bazelbuild/remote-apis/milestone/1 has been stale/stagnant for a few years now,
I want to put forward a simple question for discussion:

Should RE API V3 be considered harmful?

In my personal opinion:

• Having a non-backward compatible V3 will create many toils for both clients and servers who have adopted Remote API V3. This burden of migration will not come for free, and will likely trickle down to adopters of these clients and servers implementation.

• Leveraging Protobuf and GetCapabilities RPC, we should be able to continue developing V2 API in a backward-compatible way with a proper deprecation policy. For example, we should be able to work on Deprecate is_executable #99, or V3 idea: No longer allow Digest.size_bytes <= 0 #134, and deprecate the field after 5-10 version releases. Clients could rely on the version range provided in the GetCapabilities RPC spec to determine whether the server would support that field or not to make the appropriate adjustments.

• Being able to definitively say that there will be no V3 would allow us to encourage folks to work on more innovative changes to the API spec, instead of pushing them away to some imaginary point in the future. Instead of saying "This might be a good fit for V3", we should push forward new ideas and guide the innovators, through an RFC process, to make their ideas backward compatible as much as possible.

[EdSchouten]

Given the recent industry lessons from Golang V2 (or the lack thereof) and Nix Flakes, [...]

I don't think that Golang is a good example here. Go is a project for which there are only a relatively small number of implementations, where the reference implementation gets the vast majority of use (>99%). By stating that there will never be a Go v2, the project has effectively gone in 'append only' mode. For a single implementation this is doable. But as you stated...

Together with it is a wide list of build tools servers and vendors, https://github.com/bazelbuild/remote-apis?tab=readme-ov-file#api-users, adopting the specifications.

... we're dealing with m clients and n servers. (Maybe the same reasoning holds for Nix Flakes, but I can't say, as I've never used it.)

Trying to keep m*n client/server combinations working with a continuously changing specification takes a lot of effort. It also means that we'll keep on gaining redundant ways of doing the same thing, making it pretty hard for people in the far future to implement new clients/servers, as they will need to do a lot of catching up.

I think a better example is NFS (Network File System). There are a couple of fully distinct versions to choose from:

• NFSv2
• NFSv3
• NFSv4.0
• NFSv4.1/4.2

The main reason you have so many operating systems and hardware appliances being able to interface with each other is because designers of these systems had concrete versions that they could target.

Being able to definitively say that there will be no V3 would allow us to encourage folks to work on more innovative changes to the API spec, instead of pushing them away to some imaginary point in the future.

For me personally this would be a discouragement. There are some pretty big things I'd personally like to see changed (e.g., having a typed CAS, merging FindMissingBlobs/Write, so that client/server can negotiate which subtrees to sync, chunking). But those are so intrusive, that I can't be bothered changing those in REv2.

[EdSchouten]

Outcome of what was discussed during today's working group meeting:

https://groups.google.com/g/remote-execution-apis/c/_Um87i_KDdg