Backward compatibility lets a changed system continue supporting existing users and integrations without forcing client upgrades. It provides a graceful upgrade path for evolving APIs. section 3.4
Protect compatibility when evolving protocol buffer messages:
- Keep existing field numbers unchanged because they identify fields in the binary message format. section 3.1.1
- Reserve removed field numbers and names so future definitions cannot accidentally reuse them. section 3.1.1
- Avoid changing a field’s type or moving fields into or out of a oneof group; older and newer definitions can interpret data incompatibly or lose fields. section 3.1.1 section 3.4.5
Changing a payment request
An older CreatePaymentRequest sends both credit_card and promo_code as regular fields. If promo_code is later placed in a oneof with credit_card, one value can be lost when the older request is processed by the newer definition. section 3.4.5
message CreateOrderRequest {
reserved 1, 2, 3 to 7; #1
reserved "customer_id"; #2
int64 user_id = 7;
repeated Item items = 8;
float amount = 9;
}
Shows how to reserve removed field numbers and names while assigning new numbers to remaining fields. section 3.1.1
