[cmckn]

It’s an interesting example, knowing when to make a breaking change is really tricky in codebases like these.

You could avoid it by leaving “name” and just adding the additional fields. Maybe that’s the “right” thing to do if you have a ton of consumers and spotty test coverage. But if there’s a lot of fragile code out there (parsing “name” in subtlety different ways, etc.) it’ll never be fixed/improved. Things can get gnarly over time because there’s multiple ways to do something, and everything starts to feel like “legacy code”.

I tend to think that for private codebases, it’s important for breaking changes to be easy.