@@ -252,13 +252,18 @@ message SearchRequest {
252252
253253Deleting fields can cause serious problems if not done properly.
254254
255- ** Do not delete** ` required ` fields. This is almost impossible to do safely.
256-
257- When you no longer need a field and all references have been deleted from client
258- code, you may delete the field definition from the message. However, you
259- ** must** [ reserve the deleted field number] ( #fieldreserved ) . If you do not
260- reserve the field number, it is possible for a developer to reuse that number in
261- the future.
255+ ** Do not delete** ` required ` fields. This is almost impossible to do safely. If
256+ you must delete a ` required ` field, you should first mark the field ` optional `
257+ and ` deprecated ` and ensure that all systems which in any way observe the
258+ message have been deployed with the new schema. Then you can consider removing
259+ the field (but note that this is still an error-prone process).
260+
261+ When you no longer need a field that is not ` required ` , first delete all
262+ references to the field from client code, and then delete the field definition
263+ from the message. However, you ** must**
264+ [ reserve the deleted field number] ( #fieldreserved ) . If you do not reserve the
265+ field number, it is possible for a developer to reuse that number in the future
266+ and cause a breakage.
262267
263268You should also reserve the field name to allow JSON and TextFormat encodings of
264269your message to continue to parse.
0 commit comments