Releases and Versions

Mirox is delivered continuously. A release is one tested, versioned state of the whole platform; it is rolled out to both regions without interrupting your sessions, and every release is listed with its changes in the changelog.

The three release lines

The three lines are released independently. A platform release never requires a new agent or app, and the other way round; when a change spans two lines, the changelog says so in the entry.

What the version number means

The platform version is the one number that identifies what your organization is running. It is the version of the complete platform release — not of an individual service — and it is the number the changelog uses.

All three lines follow the same semantic-versioning schema, MAJOR.MINOR.PATCH:

• MAJOR marks a generation of the product.
• MINOR increases when a release carries a change to the data model, for example a new kind of component or setting that needs new storage.
• PATCH counts every other release: new features, corrections and improvements that leave the data model untouched.

Any increase, in any position, is a complete release that passed the same tests and was rolled out the same way.

Finding the version you are running

• In the web app the bottom of the left sidebar shows, next to the build icon, the date and time at which the web app you are looking at was built. It identifies the build of the web app itself.
• Through the API, any signed-in user and any API token can read the release:

GET /api/v1/system/version

{
  "version": "MAJOR.MINOR.PATCH",
  "build_timestamp": 1761206880,
  "region": "htz-fsn1"
}

version is the platform version, build_timestamp the build time of the answering service as Unix time, and region the region that answered. Look the version up in the changelog to see which changes it contains.

How an update reaches you

Platform. A release is rolled out region by region without downtime: the new version starts next to the old one, takes over the traffic and the old one is retired. Your session stays signed in. While the roll-out runs, the web app notices that a newer build exists and shows a small notice with a Refresh button; if you are not interacting with the page it reloads by itself after a short countdown, and it never reloads while you are typing. A release normally needs no maintenance window; one is announced only when work requires it.

Agents. The agents of your plants are updated by Mirox, independently of the platform and region by region on the agent clusters. An agent update needs nothing from your side and does not interrupt the platform; data collected during the short restart is buffered and delivered afterwards.

Mobile app. New app versions come through the App Store and Google Play. Smaller updates that do not need a store release are applied over the air when the app is next started.

Changelog and roadmap

• changelog.mirox.io lists every release, grouped by day, with the version of each line it belongs to. Entries are written for the people who run plants with Mirox, not for developers.
• roadmap.mirox.io shows what is planned, what is in progress and what has shipped, and lets you vote on items.

Frequently asked questions

Do I have to do anything for an update? No. Platform and agent updates are applied by Mirox. For the mobile app, keep automatic updates enabled in your store.

Why does the sidebar show a date rather than a version? The date identifies the build of the web app in your browser, which is what matters when a page behaves unexpectedly. The platform version is available through the API as described above.

Are both regions always on the same version? A release is rolled out to both regions in the same deployment. For the few minutes a roll-out takes, the regions can briefly differ; the region field of the version endpoint tells you which region answered.

Related pages

• Availability and Maintenance Windows — what happens when the platform is disrupted or in maintenance
• Cloud Overview — how the platform is built