本指南说明ThingsBoard的版本编号规则、各版本支持时长、何种升级需要停机，以及不同环境下应使用的Docker标签。 面向平台管理员、SRE、DevOps工程师和部署维护ThingsBoard的技术用户。
ThingsBoard版本规范
ThingsBoard版本号反映每次发布引入的变更范围，遵循语义化版本原则，便于评估升级影响。 版本号由四部分组成：MAJOR.MINOR.MAINTENANCE.PATCH。例如 4.2.1.0 表示主版本4、次版本2、维护版本1、补丁级别0。
版本号随发布中变更等级递增。
| 级别 | 变更类型 | 是否需要升级脚本 |
| MAJOR | 破坏性变更、移除/弃用API、重大迁移、新功能 | 是 |
| MINOR | 向后兼容的新功能 | 是 |
| MAINTENANCE | 缺陷修复、安全修复、框架升级 注意：通常需要升级脚本，但并非总是（如Angular 18→20） |
可能需要 |
| PATCH | 不需要升级脚本的热修复（严重缺陷/安全修复；无环境/DB变更） | 否 |
示例
4.2.0.0 — 4.2 LTS首个发布
4.2.0.2 — 两次热修复后，在 4.2.0.x 内升级无需升级脚本
4.2.1.0 — 首个维护版本；需要执行升级脚本
4.2.1.3 — 基于 4.2.1.0 的热修复；在 4.2.1.x 内可实现零停机升级
4.2.2.0 — 维护版本：含Angular升级（18 → 20）。无需DB脚本，但可能影响UI。
生命周期与支持（版本支持时长）
ThingsBoard为生产用户提供长期支持（LTS） 线路。使用LTS发布的客户可放心，其关键系统将得到保障并稳定运行。
| 发布类型 | 说明 | 支持时长 | 典型频率 |
| LTS | 每年发布；面向稳定、长期的生产使用。 | 自LTS GA起 18个月（如4.2.0.0发布日期） | 每年 |
| Standard | LTS之间的发布，含新功能。 | 自GA日起 6个月 | 每季度（Minor） |
选择合适版本
若用于生产环境：
-
优先选择处于活跃支持的latest LTS线路。
-
若要保持热修复更新，仅跟踪该线路的PATCH更新（MAINTENANCE号相同，如 4.2.1.0 → 4.2.1.3）。
-
规划维护窗口，在需要时升级到新的 MAINTENANCE 发布（如 4.2.0.x → 4.2.1.0）。
-
MAINTENANCE发布中的框架升级（如Angular 18 → 20）：
- 我们保证核心平台完整向后兼容且不要求任何升级脚本。
- 但依赖内部组件结构或CSS变量名的自定义UI代码（部件或自定义CSS）可能不可用。
- 可能影响约1% 重度自定义用户。
- 建议： 在升级到此类MAINTENANCE发布前，务必在预发布环境测试自定义UI。
Docker Hub标签策略
| 标签 | 示例 | 用途 | 更新策略 |
| M.m.P.p | 4.2.1.0 | 生产环境 | 不可变 |
| M.m.P | 4.2.1-latest | 自动安全补丁 | 浮动（在4.2.1.x内） |
| latest | latest | 开发/测试（非LTS） | 浮动（最新master发布） |
建议
-
生产环境： 固定到完整不可变标签（如4.2.1.0）。仅在更改标签时更新。
-
自动安全热修复（零停机）： 使用4.2.1.1、4.2.1.2、… ，但不要跳到4.2.2.0。
-
生产环境避免使用latest。 可能含破坏性变更，且不受LTS策略保障。
兼容性与弃用策略
-
在可行范围内，MAJOR版本内保持 API/行为兼容性。Minor发布可能弃用功能，但不应在没有迁移路径的情况下破坏现有集成。
-
弃用策略： Minor发布中标记为弃用的功能，至少会保留到下一个Minor后才移除（或在可能时通过功能开关控制）。弃用与移除均会在发布说明中说明。