本项目采用语义化版本（Semantic Versioning），版本格式统一为：
vMAJOR.MINOR.PATCH
示例：
v0.1.0
v0.11.4
v1.0.0
v1.2.3
其中：
MAJOR：主版本号MINOR：次版本号PATCH：修订版本号版本号前统一使用小写字母 v。
版本升级时，提升更高层级的版本号后，较低层级必须归零。
v1.2.9 + Bug 修复 → v1.2.10
v1.2.9 + 新增功能 → v1.3.0
v1.2.9 + 不兼容变更 → v2.0.0
格式：
v1.2.3 → v1.2.4
以下情况仅增加 PATCH：
示例：
v1.2.3 → v1.2.4
- 修复登录超时后无法重新登录的问题
- 修复 Excel 导出时日期格式错误的问题
- 优化查询性能
- 修正日志输出内容
格式：
v1.2.3 → v1.3.0
以下情况增加 MINOR，并将 PATCH 重置为 0：
示例：
v1.2.3 → v1.3.0
- 新增 Excel 批量导入功能
- 新增数据统计看板
- 新增中文/日文界面切换
- 新增邮件或企业微信通知配置
格式：
v1.2.3 → v2.0.0
以下情况增加 MAJOR，并将 MINOR 和 PATCH 重置为 0：
示例：
v1.2.3 → v2.0.0
- REST API 地址、请求参数或返回结构全面调整
- 配置文件由 YAML 改为环境变量，旧配置不再支持
- 数据库表结构重构，必须执行迁移脚本
- 原有权限模型废弃，改用新的角色权限体系
- Docker Compose 部署方式全面调整
v0.x.x 开发与试运行阶段v0.x.x 表示项目尚处于开发、验证或试运行阶段：
v0.1.0
v0.5.0
v0.11.4
该阶段的功能、接口、配置和数据结构尚未承诺稳定，可以允许一定程度的不兼容调整。
在 v0.x.x 阶段：
PATCH；MINOR；MAJOR；v0.5.3 → v0.6.0
当系统已经具备稳定的核心功能，并正式投入使用、对使用者承诺兼容性后，发布：
v1.0.0
从 v1.0.0 开始，严格遵循本规则中的 MAJOR / MINOR / PATCH 兼容性约定。
测试、验证或候选发布版本使用预发布后缀：
v1.2.0-alpha.1
v1.2.0-beta.1
v1.2.0-rc.1
v1.2.0
推荐含义：
| 后缀 | 含义 | 使用场景 |
|---|---|---|
alpha.N |
早期验证版本 | 功能开发中，可能不完整或不稳定 |
beta.N |
测试版本 | 功能基本完成，交由测试人员或部分用户测试 |
rc.N |
正式发布候选版本 | 功能冻结，若无重大问题即可发布正式版 |
| 无后缀 | 正式版本 | 可用于正式环境 |
推荐发布顺序：
v1.2.0-alpha.1
→ v1.2.0-beta.1
→ v1.2.0-rc.1
→ v1.2.0
在 Gitea 创建带有 alpha、beta、rc 后缀的 Release 时，应标记为 Pre-release（预发布）。
每一个正式版本或预发布版本都必须创建对应的 Git Tag。
Tag: v1.2.3
Release: v1.2.3
Gitea 的 Release 必须基于对应的 Tag 创建，并至少包含发布说明。
推荐流程：
完成功能开发与测试
→ 确认版本号
→ 创建 Git Tag
→ 推送 Tag 到 Gitea
→ 在 Gitea 基于 Tag 创建 Release
→ 填写发布说明
→ 如有需要，上传构建产物或部署包
每次创建 Gitea Release 时，使用以下模板：
## 新增
- 无
## 变更
- 无
## 修复
- 无
## 安全
- 无
## 不兼容变更
- 无
## 升级说明
- 无特殊操作。
如存在不兼容变更、数据库迁移、配置修改或部署调整，必须明确写在：
## 不兼容变更
和：
## 升级说明
中，并说明具体操作步骤。
晋公网安备14010702070602号