- FIDL has versioning annotations.
- FIDL offers API and ABI compatibility guarantees.
- FIDL enables soft transitions by supporting changing type definitions, adding and removing methods over time, and renaming types.
Not recommended: Avoid languages other than FIDL to define interfaces where independent evolution matters. These include: plain text, JSON, and protocol buffers.
When reviewing alternatives, ask yourself what affordances they have for evolution.
- Is there a schema for the data?
- Can the schema change over time, while providing backward/forward compatibility? How?
- What changes to the schema are API/ABI preserving/breaking? How would you know before committing a breaking change?
- Is the wire format stable?
Recommended: Be careful when designing platform APIs and ABIs for use outside the platform. Design for evolution, find ways to enforce that your clients use the intended interfaces, and don’t offer ways to circumvent the interface.
Not recommended: Avoid exposing your clients to your implementation details that are not contractual. Common mistakes include exposing broadly-scoped capabilities or namespaces, and leaking implementation details via URLs, component monikers, and diagnostics selectors.