How can you safely change a protobuf "oneof"?

At some point, we (regrettably) defined a protobuf type like this:

message Parent {
  oneof foo_or_bar {
    Foo foo = 1;
    Bar bar = 2; 
  }
}

What I want to end up with is something like

message Parent {
  oneof label {
    Foo foo = 1;
    Bar bar = 2; 
    Quux quux = 3;
  }
}

The main point is adding another field inside the oneof - that's what we want to have, one of those three things. The other thing as that unfortunately the oneof was originally named foo_or_bar but that name is no longer appropriate.

So what is the best way to do this? Just make this change and treat it as a breaking change? And is it actually that likely that it is going to break anything? The actual fields are the same, the generated accessors like getFoo() and hasBar() won't change. There is a generated method like getFooOrBarCase() but I doubt anybody is using it (this is an internal use).

Changing the name of the oneof breaks any source code you've written to use it. But, just building the code will result in compiler errors that point to all the places where work is necessary. Possibly a decent IDE these days would be able to do a project-wide namespace-sensitive find/replace, if one is afraid of a straight forward text find/replace not being specific enough.

Changing the name of the oneof won't break any existing encoded binary wireformat data, because the names are not in the data and you're not changing the field numbers for the Foo and Bar fields. The exception is JSON encoded data which probably does have the oneof's name in it.

Adding the extra field won't break existing encoded data either.

Personally, I'd just go ahead and get the schema how it should be, and just deal with the consequences for code. It's not going to be as bad as all that.

I sometimes make deliberate breaking changes in a schema (e.g. "bearing_degrees" -> "bearing_radians") in order to explore whereabouts in my code (by which I mean multiple software projects in different languages running on different systems) I might have to convert from dealing with degrees to radians (for example). Getting an answer from the CI build about how many failures there were is quicker than opening up each individual project and making an assessment by hand.

Making such a breaking change is also a good way of forcing developers to edit their code, when the meaning of something has been fundamentally changed.