发布候选版本标识优先用可追溯的commit hash

语义化版本号（major.minor.patch）能直观传达”这次发布包含什么变化”，但它要求人工判断这次改动算不算破坏性变更，还得靠 Git tag 把版本号和具体提交对应起来——持续交付的场景是一天产生几十个候选版本、每个都可能被直接推上生产，逐个手动定版号根本跟不上节奏，默认的 0.0.1-SNAPSHOT 这类占位版本号更是完全没有区分度，没法告诉你两个标着同一版本号的构建产物到底差了哪些提交。用 Git commit hash 直接作为候选版本标识，天然唯一、天然可追溯到具体代码状态，不需要任何人工定版环节；语义化版本号并没有被淘汰，而是降级为面向最终用户的”展示名”，和内部用于流水线追踪的技术标识分成两条线，各司其职。发散：这是”给人看的名字”和”给机器用的标识”该不该是同一个东西的典型分歧——持续交付把两者拆开后，才能让自动化流程摆脱对人工判断的依赖。