版本编号
Vxx.yy.zz
- xx - 产品主版本号
- yy - 产品子版本号
- zz - 功能修复或补丁版本号
依赖模块
- 基础依赖模块如 common-utils 发生任意变更时需要递增版本号，且置为 SNAPSHOT 版本
- common-pojo 等一般基于需求变更而变更的模块，建议与产品版本保持一致
- 开发及测试期间，模块版本应为快照版本，即 1.2.0-SNAPSHOT 格式
- 代码分支从开发分支合并到 master 过程中，需在开发分支将 SNAPSHOT 版本冻结为正式版，并推到 test 环境测试通过后才能发版
服务模块
- 基本规范同#依赖模块
- 服务如 content-service 依赖新版本的模块如时，即使服务本身无代码变更，也需要将 pom.xml 中 version 升级为 -SNAPSHOT 版本
CI_VERSION文件
- 对于某些模块A或服务A，所依赖的其他模块B的快照版本发生了代码变更，并需要对A重新打包时，需修改 A 下的 CI_VERSION 文件，以触发CI自动打包完成打包部署
- CI_VERSION 文件的内容一般标注当前服务或模块因何原因需要通过变更当前文件以触发CI 示例：- common-utils 富文本内容提取 FortmatUtils 变更重新打包 content-service
多分支开发
依赖模块升级(方案未拟定)
- 每个分支从 master 切出后，除了 web 服务(xxx-api)外，对依赖模块做变更，如变更：common-xxx, dao-xxx, processor-xxx 时，每个分支均需要升级依赖模块的版本，规则如下
- 当前 master 版本依赖模块 dao-xxx 的版本为 1.2.9.0，切出 3 个将要独立上线的分支 f_1.2.9.1, h_1.2.9.1, f_1.2.9.2，3 个分支均需修改 dao-xxx
- 则 3 个分支需分别升级 dao-xxx 的版本号为 1.2.9.1-SNAPSHOT, 1.2.9.2-SNAPSHOT, 1.2.9.3-SNAPSHOT
- 分支升级版本后需要记录，以便其他分支基于最新分支做升级，初定使用文档统一记录依赖模块版本变更申请(类似发号器)
- 备注
- 分支合并上线时，取依赖模块的最高版本作为合并后的版本
- 分支合并到 dev/test 时, 对应的 dev/test 依赖模块 pom 中的版本取最大值
- 若版本号较大的依赖模块先申请发布，如 h_1.2.9.1#1.2.9.2-SNAPSHOT 先于 f_1.2.9.1#1.2.9.1-SNAPSHOT 发布，则直接以 1.2.9.2-SNAPSHOT 发布，暂不冻结分支，直到 f_1.2.9.1#1.2.9.1-SNAPSHOT 合并到 pre/prod 后将依赖模块版本修改并冻结为 1.2.9.2 后发布
操作规范
- 新分支如无特殊要求，均从 master 切出
- 涉及依赖模块变更时，先申请升级版本
思考
项目中有 runner-api 依赖 monitor-common 模块，且两者都在一个代码仓库中
master 分支当前 monitor-common 版本 2.0, runner-api 版本 2.0, monitor-common中包含方法 errorNotify
LarkSender#errorNotify(String title, String errorMsg, NotifyMsgPriorityEnum priority)
###【场景一】
开发A从 master 切出分支 f_2.1, 修改了 monitor-common 的 errorNotify 方法，增加了 larkRobotUrl 参数用于指定机器人接收地址, 未升级 monitor 版本号，同时修改 runner-api 相关发消息的逻辑(使用errorNotify方法的所有逻辑都需要变更)
- 推到 test 环境打包，能否正常部署最新代码？
在上述事件发生后
开发B从 master 切出分支 h_2.0.1, 只修改了 runner-api 代码
- 推到 test 环境打包，是否需要解决代码冲突？能否正常部署最新代码？
- 开发B的 h_2.0.1 分支修复问题后可以先上线了，推到 pre 分支后能否正常打包部署？
###【场景二】
开发A从 master 切出分支 f_2.1, 在 monitor-common 新增 notifyWithSpecificUrl 方法，基于 errorNotify 方法增加了 larkRobotUrl 参数用于指定机器人接收地址, 未升级 monitor 版本号，同时修改 runner-api 相关发消息的逻辑(使用errorNotify方法的所有逻辑都改为使用 notifyWithSpecificUrl 方法)
- 推到 test 环境打包，能否正常部署最新代码？
在上述事件发生后
开发B从 master 切出分支 h_2.0.1, 只修改了 runner-api 代码
- 推到 test 环境打包，是否需要解决代码冲突？能否正常部署最新代码？
- 开发B的 h_2.0.1 分支修复问题后可以先上线了，推到 pre 分支后能否正常打包部署？
