Adding new methods to the gRPC interfaces is backwards-compatible at the gRPC level and thus the major version of the CSI spec repo is not incremented. However, the way how the Go bindings were generated broke compatibility with existing CSI drivers because they had to implement at least stubs for the new methods.
It would be nice to use this for the Go bindings, ideally for all methods that were added after CSI 1.0.0. Alternatively it might also make sense to enable it for all optional methods.
The downside is that unintentionally missing to implement some method is not caught anymore during compilation.
Note that I have not investigate whether it is possible to add methods selectively to Unimplemented<Service>Server. It might that the require_unimplemented_servers=false is an all-or-nothing switch.
Adding new methods to the gRPC interfaces is backwards-compatible at the gRPC level and thus the major version of the CSI spec repo is not incremented. However, the way how the Go bindings were generated broke compatibility with existing CSI drivers because they had to implement at least stubs for the new methods.
https://github.com/grpc/grpc-go/releases/tag/cmd/protoc-gen-go-grpc/v1.0.0 describes how
Unimplemented<Service>Server
can be generated and embedded in the interface definitions, which solves the issue.It would be nice to use this for the Go bindings, ideally for all methods that were added after CSI 1.0.0. Alternatively it might also make sense to enable it for all optional methods.
The downside is that unintentionally missing to implement some method is not caught anymore during compilation.