Skip to content

Cookie preferences

We use cookies for our own analytics, to see how our campaigns perform and, if you allow it, to load content from other services such as the Google site search. We never sell your data. Necessary cookies keep the site working and cannot be switched off. See our Cookie Policy for details and our Privacy Policy for how we handle personal data.

Security, load balancing and remembering your cookie choice.

Show us which pages people read, how they find the site and where they get stuck, so we can improve it (Google Analytics, Microsoft Clarity).

Show us which of our ad campaigns bring visitors to the site and remember the campaign or partner link you arrived from (Google Ads, LinkedIn, Meta, partner program). We do not use these cookies to build advertising profiles.

Load the site search from Google when you use it. Google sets its own cookies and shows ads in the search results.

© 2026 The ThingsBoard Authors
22.5k Try for free

ThingsBoard Cloud

Choose your data region

Your data stays in the region you choose, for residency and compliance. No credit card required.

Rather run it yourself? Install on your own servers

Versioning and Release Policy

This guide explains how Trendz Analytics versions are numbered, when upgrade scripts are required, and which Docker tags to use in different environments. It is written for platform administrators and DevOps engineers who deploy and maintain Trendz Analytics.

Trendz Analytics uses a four-part version number: 1.MAJOR.MINOR.PATCH.

  • The first number is always 1 and represents the current major product line.
  • MAJOR identifies the major release — it increments when significant new features or architectural changes are introduced.
  • MINOR identifies the minor release — it increments for critical bug fixes or database schema changes within a given major release, without changing product features or behavior.
  • PATCH is the build (hotfix) number — it increments for image-level fixes that do not require database changes.

Example:

  • 1.14.0.0 — initial major release 14
  • 1.14.0.3 — third hotfix for 1.14.0; no database changes
  • 1.14.1.0 — first minor release within major 14; upgrade scripts required
  • 1.15.0.0 — next major release; upgrade scripts required
Release type What changes Upgrade scripts required
Major MAJOR number. Significant new features or architectural changes. Yes
Minor MINOR number. Critical bug fixes, security fixes, or database schema changes within the same major release. Does not change product features. Yes (even if no schema changes — a stub script is always provided)
Patch PATCH number. Hotfix builds — no database or environment changes. No

Every major or minor release ships with a database upgrade script. If no schema changes are required, a stub script is provided to maintain a consistent upgrade path. All upgrade scripts are idempotent: they can be applied multiple times without corrupting data.

Tag format Example Use
1.MAJOR.MINOR.PATCH 1.15.0.5 Pinned production tag — immutable
1.MAJOR.MINOR-latest 1.15.0-latest Tracks the latest patch within a minor release — floating
latest latest Tracks the latest released build — avoid in production

Recommendations:

  • Production: Pin to the full immutable tag (e.g., thingsboard/trendz:1.15.0.5). Upgrade only by explicitly updating the tag and running the upgrade script for the target version.
  • Auto patch updates: Use 1.MAJOR.MINOR-latest (e.g., thingsboard/trendz:1.15.0-latest) to automatically receive new patch builds within the same minor release. No upgrade scripts or downtime required.
  • Avoid latest in production. It tracks the most recent build and may include breaking changes.
Release type Description Support duration Typical frequency
LTS For stable, long-term production use 18 months from initial release date Annually
Standard Releases between LTS lines, including new features 6 months from initial release date Every three months

Trendz Analytics supports direct upgrades from any version to any other version — you do not need to apply intermediate upgrade scripts step by step. For example, you can upgrade directly from 1.12.0.0 to 1.15.0.0 in a single step.

Patch releases within the same minor version (e.g., 1.15.0.0 → 1.15.0.5) require no upgrade script and no downtime — update the Docker image tag only.