关于产品研发测试运维对软件项目版本号规范

业务中,对于版本的创建到发布,涉及产品、研发、测试、运维等存在不同阶段的命名要求,参考别的厂规范,如下:

版本号命名规则:

{soft}{major}.{minor}.{version}.{date}{stage}.{sprint}

比如目前4.0的sprint2的发布:iflystar_4.5.3.20250107_alpha.2

ps:以上版本对外发布,由软件项目经理控制版本号;

版本号字段用途解释:

soft: 软件名

major: 大版本更迭

minor: 小版本更迭

version: 修订版本记录,比如一轮测试中修复重大bug后持续发布则+1

sprint: 迭代周期,一次小版本开发中每个周期发布可添加sprint号,完成一次小版本所有sprint后发布,可以去掉该号,比如iflystar_4.5.3.20250107_alpha 即可;

date: 发布日期

stage: 软件开发阶段,包括alpha、beta、rc、release

alpha :内测版本,bug多,不稳定,包括发布集成测试及系统测试;

beta : 外部小规模测试版本,比如发布现场poc版本,小范围客户试用版本,公司发布公测版本等;

rc(可选) : 准备正式发行版本,正在进行转产测试版本;

release : 正式对外发行版本

研发提测给测试,版本需加 alpha,同一个版本多次提测需要添加sprint

测试封版给运维,版本需加 release,同一个版本多次上线需要添加sprint

欢迎大家补充和讨论

相关推荐
PPPHUANG2 天前
一次 CompletableFuture 误用,如何耗尽 IO 线程池并拖垮整个系统
java·后端·代码规范
zhouzhouya2 天前
码上星辰,人间烟火:我的2025
前端·程序员·代码规范
程序员Agions2 天前
程序员邪修手册:那些不能写进文档的骚操作
前端·后端·代码规范
晨米酱2 天前
轻量级 Git Hooks 管理工具 Husky
前端·代码规范
parade岁月3 天前
把 Git 提交变成“可执行规范”:Commit 规范体系与 Husky/Commitlint/Commitizen/Lint-staged 全链路介绍
前端·代码规范
哈基闻3 天前
想要更多,那就“多继承”
代码规范
zhz52144 天前
后端代码规范文档示例
重构·bug·代码规范·结对编程
卖火箭的小男孩6 天前
Flutter 开发代码规范(优化完善版)
flutter·代码规范
Piper蛋窝6 天前
AI 有你想不到,也它有做不到 | 2025 年深度使用 Cursor/Trae/CodeX 所得十条经验
前端·后端·代码规范
莫比乌斯环7 天前
【安全专项】如何成为一名“火眼金睛”的安卓侦探?
前端·代码规范