Backward-compatible field/message rename

[JanecekPetr]

When using text format, JSON format, or any FieldMask features, it is not safe to rename messages/fields. We're using text format for various things, mostly complex configuration files; and a FieldMask is occasionally useful, too.

Over time, the inability to rename old fields and messages is a bigger and bigger issue for us.

Would it be possible to add a way to rename and/or alias fields and messages in text-backward-compatible way? Having a new option seems to me to be the easieast approach to me currently:

int32 new_name = 6 [alias="old_name", alias="oooold_name"];

message NewMessageName {
    option alias = "OldMessageName";
}

These options would be disregarded when parsing from the wire, but could be taken into account when parsing from any text representation (or when using FieldMask).

The biggest issue I can see that this clashes with how currently enum aliasing works.

(related to #3793)

[JanecekPetr]

Obviously I can provide a PR for this for the general compiler, and for Java text-format and JSON-format parsing. I won't be able to provide the same for other languages, though.

Is there any will to ever have this done? I'd like to propose a collaboration on this for other languages and/or docs.

[ghost]

I don't think there is a strong will to get this done. Would it be possible to migrate the configurations to use the new name instead? I think what other people have done in similar situation is:

• Create a new field with the desired name.
• Make sure that everyone is writing the same data to both old and new fields.
• Start reading from the new fields.
• Stop using the old fields and remove it.

[JanecekPetr]

Thank you for your feedback. Yes, your suggested approach is possible and it's the way we'll need to take. (Except the extra code and fields will probably need to stay forever - there're so many configuration files across many production environments already that it's unlikely to ever migrate them all. Not a big problem, just a minor annoyance.)

We simply hoped to strenghten the protobuf schema evolution story because that we feel is the main feature of the language and the libraries. It should not be needed to add code and new fields instead of just renaming fields as that is expected to be a "safe" operation.

That said, I understand that such a feature requires a lot of work in a lot of places with little benefit and does probably not carry its own weight if not many people are using text-formattted and/or json-formatted protobufs.

Thanks, feel free to close this ticket completely. Or not if you like to keep never-gonna-happen feature requests open.

[TeBoring]

Close this for clean up.