A Software Update Promise Is Not a Support Agreement

Smart equipment buyers often read a version string on a controller, gateway, or edge module and assume it carries a promise about future care. A label such as 2.4.1 tells you how the producer numbered a release inside its own scheme; it does not by itself tell you who owns the equipment after the sale, how long patches will arrive, or which third-party libraries must keep working. For procurement teams, the gap between a numbering convention and a real support arrangement is where risk hides. The fix is documentation: ask for dependency lists, release-support statements, and end-of-support ownership in writing, while treating semantic version labels as a communication tool rather than a warranty.

What a Semantic Version Label Actually Communicates

Semantic versioning, often shortened to SemVer, uses a three-part number made of nonnegative integers: major, minor, and patch, written as MAJOR.MINOR.PATCH. According to the specification at semver.org, a patch version is incremented if only backward compatible bug fixes are introduced, a minor version for backward compatible additions to a declared public interface, and a major version for backward incompatible changes to that interface. Pre-release tags and build metadata may be appended, and build metadata is ignored when comparing which release is newer. The scheme assumes the producer has declared a public interface, either in code or in documentation, and that the interface is precise enough for others to rely on.

For smart equipment, that interface might be a machine-to-machine command set, a robot controller API, or the message format used by a sensor gateway. The label helps your integration team anticipate whether moving from one firmware build to another could break a dashboard, a data pipeline, or a safety-monitoring script. What it does not promise is continuing vendor attention. A vendor can publish 3.0.0 and then stop issuing updates entirely; the SemVer rule describes how numbers change when changes are made, not that changes will be made. Nor does the label identify the operating system, middleware, or communication libraries bundled inside the device software.

Why Dependency Records Matter More Than the Version String

The SemVer document describes a problem it calls dependency hell: when a system grows and many software packages are integrated, tight dependency rules can cause version lock, while loose rules can cause unreasonable assumptions about future compatibility. In smart equipment, the equivalent problem appears when a vendor ships a controller that depends on a specific networking library, a container runtime, or a protocol stack, but does not tell you which versions are inside the image. You may later discover that a minor firmware bump pulled in a newer transitive component that your plant monitoring system was not tested against.

A recommended documentation practice for procurement is to request a software dependency inventory for each equipment model in scope. That inventory should name direct third-party components and the device-side interfaces they touch, together with the version ranges the vendor actually tested. If the vendor uses SemVer for its own packages, the document should state which major line your purchased units are qualified against, because a major increment signals a possible incompatible interface change. Keep this inventory as a living record; when a new firmware image arrives, compare its component list with the earlier one and note any difference for observation, not repair.

Reading Major, Minor, and Patch on a Device Label

Suppose a vendor labels two releases as 1.8.4 and 1.9.0. Under the SemVer rules, the move from 1.8.4 to 1.9.0 indicates new backward compatible functionality or possibly internal improvements, with the patch number reset to zero. It does not indicate that security patches for 1.8.4 will continue, nor that the 1.9.0 release is more secure. A move to 2.0.0 would indicate an incompatible interface change, which is a planning signal for your integration engineers to revalidate connections before deployment. A pre-release tag such as 2.0.0-rc.1 has lower precedence than the normal 2.0.0 release and signals an unstable build that may not meet the compatibility expectations of the normal version.

Buyers should also note the special status of the zero major version. The specification says that major version zero is for initial development and that anything may change at any time; the public interface should not be considered stable. If a robotics cell controller ships as 0.7.2, treat the interface as provisional in your test plan even if the equipment is physically installed. This is a documentation observation for acceptance testing, not a statement that the machine is unsafe or noncompliant.

Support Scope Is a Separate Document From Versioning

A version string is produced by the developer's release process; a support agreement is a commercial and operational commitment. For procurement, ask the vendor for a release-support statement that names the supported major lines, the minimum notice before a line is deprecated, and the channel through which security or bug-fix releases are distributed. The statement should also say whether the vendor will continue to sign, publish, and verify images after a line leaves active development. If the answer is only verbal, record it in your own purchase file with the date and the person's role, because memory is not a control.

NIST guidance on software supply chain security, published under Executive Order 14028 at nist.gov, identifies criteria to evaluate software security and criteria to evaluate the security practices of developers and suppliers, together with methods to demonstrate conformance with secure practices. That guidance was developed after soliciting input from private sector, academic, and government respondents. It is relevant context for why you should ask suppliers how they manage components and updates, but it is not an endorsement of any particular buyer's checklist, and it does not turn a vendor's SemVer label into a certified support contract.

End-of-Support Ownership and Succession Planning

One of the most useful procurement questions is who owns the software after the original product line ends. If a device vendor is acquired, discontinues a model, or moves its platform to a new architecture, the equipment in your facility may still need a way to receive verified updates or, at minimum, a documented path to isolate it from networks it can no longer safely trust. Ask for the end-of-support owner: the named organizational function or successor entity responsible for publishing the final firmware, the dependency manifest, and the known-interface description after active sales stop.

Recommended documentation practice here is a single page per equipment family that records: the last supported SemVer line, the date the vendor says support ends, the named owner of the final image, and where the dependency inventory is stored. A hypothetical example makes this concrete: a warehouse autonomous mobile robot fleet is bought with controller software labelled 4.3.0. The vendor document says line 4.x is supported for three years and that after discontinuation the successor company's embedded software team owns the final image and manifest. Your procurement file records that line, those dates, and the successor contact. Two years later, when the vendor announces end of sale, your team already knows which line to freeze and whom to ask for the final verified build. No repair action is implied; this is observation and recordkeeping for continuity.

A Practical Documentation Checklist for Buyers

The following checklist turns versioning knowledge into purchasing documents. It is a recommended documentation practice, not a requirement imposed by the SemVer specification or by NIST.

First, for each smart equipment item, capture the installed SemVer string and the public interface description the vendor declares for that string. Second, request the dependency inventory covering third-party libraries, runtimes, and protocol components, with the versions tested inside the shipped image. Third, obtain the release-support statement naming supported major lines and deprecation notice. Fourth, record the end-of-support owner and the location of the final manifest. Fifth, create a change log for every firmware or software image you accept, noting the old and new SemVer values and any dependency differences you observed. Sixth, store all of these with the purchase order and the vendor contact role so that future buyers of the same equipment line can reuse the file. For more procurement writing on this subject, see our technical guides and the industry updates index.

Turning Observation Into Procurement Discipline

When your team treats a version label as information rather than assurance, the procurement conversation changes. You stop asking whether 2.0.0 is "good" and start asking which interfaces changed, which dependencies moved, and who will still be responsible if the vendor stops publishing. The SemVer specification gives you a shared vocabulary for interface compatibility, and NIST supply chain guidance gives you a reason to ask suppliers about their component and update practices. Neither document replaces the support terms you must write into your own records.

For smart equipment with long physical lifetimes, the software half of the asset often outlives the sales cycle of the original model. Recording SemVer values, dependency inventories, support windows, and end-of-support ownership creates a file that later engineers can read without guessing. That file, not the version string on the device label, is what turns a software update promise into a manageable procurement record.