How do you handle versioning and backward compatibility of subgraph schemas?

A federated graph changes constantly across many independently-owned subgraphs, so backward compatibility is managed through process as much as through schema design.

• Schema checks in CI – run rover subgraph check against real production traffic samples before merging, so a potentially breaking change is flagged against actual usage, not just against the abstract schema.
• Deprecate before removing – mark a field @deprecated(reason: "...") and let it sit for a migration window before deleting it outright.
• Watch field usage – GraphOS reports which clients are still calling a given field, so you know when it's actually safe to remove.
• Use @override for ownership migrations rather than an instant cutover, so a field can move between subgraphs gradually with a rollback path.
• Use contracts to give some client segments a more stable, filtered schema surface while the underlying graph evolves faster than that.

The common thread across all of these is visibility: none of it works well without knowing, with real data, who is actually depending on the field you're about to change.