Marking a message as reserved raises an error about buf

[nicksnyder]

What level of breaking change detection do you have configured? Here are the options: https://buf.build/docs/breaking/rules

The default is FILE level, which will report breaking in this case because removing a field from generated code will break source code that is referencing this field in the generated code.

If you only care about WIRE compatibility, you can use that mode, but generally we recommend sticking with FILE (which is why it is the default).

[epot]

We are using the PACKAGE option because the FILE one was too noisy. I am not sure I understand why it triggers, I mean this change should be fine no? If you are recommending sticking with FILE, then what is the recommended way to deprecate a field without triggering a failure?

[bufdev]

You'll want to review the meaning of the different breaking categories: FILE, PACKAGE, WIRE_JSON, WIRE at https://buf.build/docs/breaking/rules#categories.

Deleting a field is a source-code breaking change, regardless of if it is reserved - the generated code that results from your Protobuf APIs will have code deleted that users may depend on. The goal of the FILE and PACKAGE categories is to prevent you from breaking source code. Conversely, the WIRE_JSON and WIRE categories are all about wire-compatible breaking changes. If either of these categories was specified, then the FIELD_NO_DELETE rule is replaced with FIELD_NO_DELETE_UNLESS_NUMBER_RESERVED (and FIELD_NO_DELETE_UNLESS_NAME_RESERVED for WIRE_JSON).

If you'd like to allow source-code breaking changes (such as deleting fields), but enforce that there are no wire-compatible changes, change your category to WIRE if you only care about binary compatibility, or WIRE_JSON if you also care about JSON compatibility.