Compatibility and Limits

Vexil's first wire-format generation is stabilizing and the language specification remains a draft. Repository tests provide substantial internal evidence, but the format has not been independently implemented or audited.

Before adopting Vexil

1. Select the exact generated targets from the support matrix.
2. Compile and round-trip the schemas your application will ship.
3. Compare generated bytes across every participating language.
4. Define framing, authentication, resource limits, and schema distribution at the application layer.
5. Test rolling upgrades with vexilc compat and real old/new peers.

What hashes and compatibility checks do not do

A matching schema hash says two peers compiled the same canonical contract. It does not authenticate the peer, negotiate a transport, validate business rules, or prove that the surrounding application uses the codec correctly.

vexilc compat classifies schema changes according to the specification. It does not prove application-level compatibility, migration correctness, or safe deployment order.

Adding a message field is classified as breaking. Message values are not internally length-delimited, so nested and aggregate decoders cannot infer the old value boundary safely. Prefer a new declaration and explicit migration over an EOF-based default.

Maintained detail

The repository's Compatibility and Current Limits page records verified behavior, adoption boundaries, unavailable capabilities, and the evidence level for performance claims.

For a hands-on path, continue to Project Evolution.