4. 版本标识与命名规范
在WAGO控制器项目中，版本治理的第一道防线不是工具，而是命名。一个工程师打开共享盘或Git仓库时，如果看到的是 Program_Final_v2_new(1).pro 这样的文件，那么无论后面配置多严格的审批流程，变更追溯都已经失败了。本节要解决的核心问题是：为WAGO项目建立一套“人看得懂、机器能解析、工具可排序”的版本标识体系，覆盖版本号、文件命名、目录结构、标签和基线五个层面。
一、版本号规则：语义化版本在PLC项目中的落地
WAGO项目通常包含PLC程序（CODESYS工程）、HMI画面、参数配置、库文件和文档。推荐采用三段式语义化版本号 MAJOR.MINOR.PATCH，并附加WAGO项目特有的构建元数据。定义如下：
- MAJOR（主版本）：当控制逻辑架构发生不兼容变更时递增，例如从单轴控制改为多轴联动、I/O映射整体重构、通信协议从Modbus RTU切换到Profinet。主版本变更意味着现场必须整体重新下载并重新验证。
- MINOR（次版本）：当新增功能或新增设备但保持向后兼容时递增，例如增加一个报警页面、新增一段PID回路、扩展一个远程I/O站点。
- PATCH（修订号）：当修复缺陷、调整参数、优化注释而不改变接口时递增，例如修正定时器预设值、修复HMI按钮地址错误。
完整版本标识建议写成 V2.3.1+20240612.1，其中 + 后为构建元数据：日期 YYYYMMDD 加当日构建序号。这样即使同一天多次提交，也能区分先后。对于WAGO 750系列控制器，还可在版本号后附加目标硬件标识，例如 V2.3.1+20240612.1-750-8212，避免将PFC200的程序误下载到CC100。
二、文件命名：让文件名自带上下文
WAGO项目文件命名推荐采用“项目代号_模块_版本_状态.扩展名”的结构。例如：
WAGO_LINE2_MainProgram_V2.3.1_Released.project
WAGO_LINE2_HMI_Overview_V1.4.0_Review.hmi
WAGO_LINE2_IOConfig_V2.3.1_Released.xml
WAGO_LINE2_Library_MotorLib_V1.0.2_Released.library关键约束有四点：第一，不使用空格，统一用下划线分隔，避免脚本解析时截断；第二，状态字段只允许 Draft、Review、Released、Deprecated 四种，与后续基线状态一一对应；第三，日期不写入文件名主体，日期信息由版本号构建元数据或Git提交时间承载，防止文件名过长；第四，禁止出现 final、new、ok、改 等无信息量词汇。
三、目录结构：按“项目—模块—类型”分层
目录结构决定了一个新成员能否在五分钟内找到目标文件。推荐WAGO项目采用三层结构：项目层、模块层、类型层。项目层以项目代号命名；模块层按控制对象划分，如 MainProgram、HMI、IOConfig、Libraries、Docs；类型层存放具体文件。版本文件不直接覆盖，而是通过Git分支或标签管理，工作区只保留当前Released版本。
四、标签：Git中的版本锚点
在Git仓库中，标签是版本标识的最终锚点。WAGO项目建议同时使用轻量标签和附注标签：轻量标签用于日常内部提交，如 v2.3.1；附注标签用于正式发布，如 v2.3.1-rc1，并在标签消息中记录发布说明、验证人、目标硬件型号和关联的变更单号。例如：
git tag -a v2.3.1-rc1 -m "Release V2.3.1 for 750-8212; verified by Zhang; CR-2024-0612"标签一旦推送，不允许移动或删除。若发现标签指向错误提交，应新建一个更高PATCH号的标签来修正，并在发布说明中注明废弃原因。对于WAGO项目，建议在标签名中避免使用 /，因为部分CI脚本对斜杠处理不一致，统一用连字符。
五、基线：可交付的完整快照
基线是版本治理中“可交付”的正式节点，它不等于单个标签，而是一组标签的集合。一个WAGO项目基线应包含：PLC程序标签、HMI标签、IO配置标签、库文件标签、文档标签，以及一份基线清单文件。基线命名推荐 BL_日期_版本号，例如 BL_20240612_V2.3.1。基线清单可采用如下结构：
| 组件 | 版本标签 | 状态 | 验证人 |
|---|---|---|---|
| MainProgram | v2.3.1 | Released | 张工 |
| HMI | v1.4.0 | Released | 李工 |
| IOConfig | v2.3.1 | Released | 张工 |
| MotorLib | v1.0.2 | Released | 王工 |
| Docs | v1.1.0 | Released | 李工 |
基线建立后，现场下载记录必须回写基线编号。例如在WAGO控制器的项目信息中写入 BL_20240612_V2.3.1，或在HMI启动画面角落显示该编号。这样当现场出现异常时，工程师可以第一时间确认设备运行的是哪个基线，而不是靠记忆或翻找邮件。
BL_20240613_V2.3.2，并在变更单中说明与前一基线的差异。禁止在原基线标签上直接修改文件，否则追溯链断裂。六、落地检查清单
在项目启动阶段，建议将以下检查项纳入WAGO项目的配置管理计划：版本号三段式是否定义并写入README；文件命名是否通过脚本校验；目录结构是否按项目—模块—类型分层；Git标签是否采用附注标签并包含验证信息；基线清单是否覆盖程序、HMI、IO、库、文档五类组件；现场下载记录是否回写基线编号。完成这六项，版本标识体系即可支撑后续的变更申请、影响分析和发布审计。
需要强调的是，命名规范的价值不在于“好看”，而在于可解析、可排序、可追溯。当CI脚本能够从文件名中自动提取版本号和状态，当Git标签能够直接关联变更单，当现场设备能够显示基线编号，版本治理才真正从文档约定变成了工程能力。