Skip to content

Reading an EEI Version Number

Version numbers carry more implied meaning than most of them have earned. This page says exactly what ours tell you, so you are not reading a promise into a digit.

The shape

major.minor.trailing          e.g.  1.14.0   ·   100.35.137

Three positions, most significant first. Two properties are worth knowing before you compare two of them:

  • Every position moves forward. Our numbers do not go backwards.
  • No position stops at 9. These are integers, not digits. 100.35.137 is an ordinary release number, and 1.14.0 is newer than 1.9.0 — not older. If you sort our versions programmatically, compare each position as a number; a plain text sort will put them in the wrong order.

What the number does not tell you

It is not a semantic version, and we do not use the positions to grade a change.

A bump in minor does not mean "a new feature." A bump in the trailing position does not mean "a small fix." Both mean one thing: this is later. A change in major is the one we treat as deliberate and significant.

We do it this way on purpose. Encoding "this release is minor" into a number invites you to skip the release notes, and the encoding is wrong the first time a one-line change turns out to matter. The number puts releases in order. The release notes tell you what changed. We would rather you read the second one.

So please do not infer compatibility from it. No arithmetic on our version number tells you what it runs against. Every release states the platform version it was validated against, and that statement is the answer — see your product's compatibility page.

Connectors: why the number starts with something like 100.35

For our Seeq connectors the first two positions are not ours. They are taken directly from the Seeq Link SDK line the connector was compiled against, so that anyone — you, Seeq, or one of our engineers — can read a deployed bundle and know what it was built from without a lookup.

That makes the prefix build provenance. Three things follow, and each one catches people out:

  • It is not a Seeq server version. Seeq maintains separate version lines for Seeq Server and for its Connector SDK, and the prefix follows the SDK line. The two cannot be derived from each other. The Seeq platform version a release was validated against is a different number entirely, and it is stated explicitly on each release.
  • It is not a compatibility range. The connector does not bundle the SDK; the Seeq agent supplies it at runtime. The prefix tells you what to expect, not what is enforced.
  • The trailing position is the part we own — and it is cumulative. It is our own build counter for that connector, it only ever increases, and it does not reset when the Seeq prefix moves. That is deliberate: since we do not control the first two positions, a counter that reset whenever Seeq's numbering jumped would erase the one continuous record of our own work on that connector, at a moment we did not choose. Left to accumulate, it spans the connector's whole life. (It counts builds rather than releases, so read it as continuity and ordering, not as a release tally.)

A moving prefix is expected. When we adopt a newer Seeq SDK, the prefix moves with it — a connector can go from 100.14.x to 100.35.x. That is not a renumbering of the product or a signal of upheaval; it is the clearest available indication that the build now targets a newer Seeq. We track Seeq's releases and validate before adopting, so this happens on our schedule and is delivered with you rather than to you.

What to look at instead

Question Where it is answered
Which Seeq version was this validated against? Your product's compatibility page, and the release notes
What changed in this release? The product's release notes
Is this newer than what I have? Compare each position as an integer — or just ask us
How do you keep up with Seeq releases? Validating Seeq Integrations Against Seeq Continuous Delivery — platform currency is our work, not yours