gRPC message request versioning with a version field - grpc

Question

It appears that through all documentation there is very little dedicated to gRPC versioning best practices. Overall what I understood is that things should be kept simple, such as not removing fields or their orders and proceed with evaluating what is the set of fields that are part of the message.
I was planning on simply defining a standard to my messages that includes a version field as the first in order, such as:
message userCreateRequest {
string version = 1
string name = 2;
string lastName = 3;
}
With the above, the version field could be treated to retrieve the right "versioning intention" by clients. As a default it vcould be "v1.0" and from that the service would verify how to handle the expectations.
example v1.0 request:
userCreateRequest {
version: "v1.0",
name = "jim",
lastName = "smith"
}
example v2.0 request:
userCreateRequest {
version: "v2.0",
name = "jim",
lastName = "smith"
}
Question: is this against any guidance or best practice?

Answer 1

The major version number should be part of the proto package, like your.package.v2. This is the recommendation of the Google API design guide (which is targeted to gRPC services also providing REST). Because the version is part of the package name, each major version is considered a separate service.
If the major version number is 1, then while it may not be essential to have the version number in the package name, it is still a good idea to reduce confusion.