An API version is a promise to the rest of the vehicle

Vehicle software teams often discuss interfaces as if a version number were enough to establish compatibility. In practice, another component relies on behaviour as well as syntax. A message may still parse correctly while carrying a changed meaning, arriving differently or becoming unavailable during a restart. Interface management should treat that reliance as a product promise.

The issue becomes more visible when software from several suppliers shares a platform. Each team can make a locally sensible change that creates a system-level incompatibility. A clear version policy makes the consequences visible early enough for the programme to manage them.

Catalogue the consumers first

Before changing an interface, identify the components that consume it and the vehicle configurations in which those components operate. Include diagnostic tools and backend services where relevant. An interface described as internal can still have a long support life if a workshop application or field investigation tool depends on it.

AUTOSAR Adaptive provides a reference context for service-oriented applications. The editorial lesson is that discoverable services still need governed contracts. Discovery can tell software that a service exists; it cannot by itself explain whether a particular consumer will interpret that service safely or usefully.

Define what counts as a breaking change

Agree which changes require consumer adaptation. Removing a field is an obvious candidate, but so are changing units, altering a default value or redefining a fault state. Timing and resource behaviour may also matter. Write examples drawn from the actual interfaces so teams can apply the policy without debating terminology at every release.

Adding optional information may be compatible only if existing consumers ignore it correctly. Test that assumption. A theoretically extensible format can be handled by a parser that rejects unfamiliar content. Compatibility should refer to the delivered implementation and its verified behaviour, rather than the intentions of the format designer.

Plan coexistence deliberately

If old and new consumers must operate together, specify the supported combinations and the duration of coexistence. Decide whether an adapter will translate between versions, which team maintains it and which behaviour it cannot translate faithfully. An adapter is another component with its own failure modes, resource demand and test burden.

Vehicle updates complicate the transition because components may not all change at once. Design the migration sequence alongside the interface change. Identify any temporary configuration that would leave a consumer connected to a provider it cannot use, and prevent deployment from reaching that state without an approved recovery path.

Make retirement an evidence-based decision

A version can be retired when the programme understands where it remains in use and how those installations will be supported. Repository searches alone are insufficient if vehicles, workshops or partner services contain older consumers. Combine development records with the available installed configuration information.

Assign ownership to the compatibility decision, not merely to publishing a document. A version policy needs an authority that can resolve contested changes and accept the resulting maintenance cost. That turns versioning into a useful planning tool. The number then marks a promise that teams understand, rather than disguising assumptions that they will discover during integration.