The OTM .NET Packages Jump From 1.1 to 5.7

On 4 August 2025, all three OTM .NET packages sat at version 5.7.1.1. A month earlier, at their first release, they were still on 1.0.x and 1.1.1.x. That number is no typo in a release pipeline; it answers the question everyone asks when pulling in a client library for a standard: which version of the standard is actually in here?

For anyone arriving here cold: what is OTM? The Open Trip Model is an open standard for exchanging logistics trip data (trips, consignments, transport orders, vehicles, locations, goods and events) as lightweight JSON over a REST API. The standard exists to stop every party in the chain from building its own translation layer to every other party. Since 2018 it has been stewarded by the Stichting Uniforme Transport Code, together with TLN, evofenedex and DALTI, and it ships in versions: 5.4 in May 2022, 5.5 in February 2023, 5.6 in November 2023, 5.7 in May 2025.

A client library for a standard has two versions that matter at once: the library's own, and that of the standard inside it. As long as you number those separately, every upgrade means digging through release notes to see whether you now speak 5.6 or 5.7. And when a counterparty asks which OTM version your integration supports, the honest answer is: "let me check."

That is exactly the friction a standard is supposed to remove.

The change happened in two steps:

• 31 July 2025: OpenTripModel.Profile goes first, from 1.1.1.8 into the 5.7 series.
• 4 August 2025: OpenTripModel.Model and OpenTripModel.Serializer follow, both to 5.7.1.1.

From that moment 5.7.1.1 tells you two things at once: this speaks OTM 5.7, and this is the second patch of this library against it. There is a price. Semantic version numbers lose their usual meaning: the major no longer signals a breaking change in the library, but the version of the standard. A breaking change in the library itself has to land somewhere else in the number.

For a client library of a standard that is a defensible trade. In practice, "which OTM do you speak" gets asked far more often than "is this upgrade breaking".

Interestingly, the Java side did not follow. org.opentripmodel:otm-toolkit appeared on 9 July 2025 as 1.0.1.0 and keeps its own numbering. That is defensible, and it is also an inconsistency between two libraries otherwise clearly built from the same design: the same three-way split into model, profile validation and serialiser, the same decision not to ship a transport layer.

If you use Java and .NET side by side, and in logistics that is the rule rather than the exception, it means the package number is enough for .NET while for Java you still have to open the documentation.

Two practical things. Put the OTM version in your interface documentation, not the library version number. Even if they happen to be identical right now. The day one of the two libraries changes scheme, you do not want to discover that your contract documentation points at a package version. Add a check to your pipeline that logs the OTM version in use. Not because you need it daily, but because otherwise the question "are we still on 5.6?" can only be answered by reading a lockfile.

And the question hanging over all of this: will such a library keep up with the standard? A client library that lags is more dangerous than no client library at all, because a version number saying 5.7 implies you are current. That is a promise you can only judge at the standard's next release. Until then: the number tells you which version was inside when it shipped, not whether that is still the latest.

At Keana, our planning software for green city logistics, every new shipper or carrier connects to the same standard. The less conversation needed about which version everyone speaks, the faster that connection is done. A version number that answers the question by itself saves more time in practice than it sounds like. See the Keana case. On 31 July 2025 OpenTripModel.Profile moved to the 5.7 series; on 4 August OpenTripModel.Model and OpenTripModel.Serializer followed, both to 5.7.1.1. Since then the .NET packages' version number carries the version of the standard inside them; the Java toolkit keeps its own 1.0.x series.

I think it is a good trade, and I wish Java had followed: the question "which OTM do you speak" gets asked far more often in practice than "is this upgrade breaking". But do not let it lull you. A number that says 5.7 tells you which version was inside when it was released, not whether that is still the latest, and at the standard's next release you will see whether the library keeps pace. So put the OTM version in your interface documentation and log it in your pipeline, and at that release you will not be the one digging through a lockfile. Setting that up is part of how we deliver integrations in custom software development.