搜索
  • 各位公司对版本号有没什么好的管理方式，还是每次新版就增加上去？
  • 发布于 1天前
  • 33 热度
    10 评论
  • Kily
  • 0 粉丝 37 篇博客
  •   
 如题，v1.0.0，各位公司对版本号有没什么好的管理方式，还是每次新版就增加上去？，v1.0.0，想看看有没普遍认可的版本号管理规则，基本上安卓和 iOS 有版本号管理，后端和前端算是没有，当然最好的做法也是需要。各位的公司是怎么制定版本号的？
用户评论
  • Zappos
  • 版本号本身会使用语义化版本 semver2 ，实际使用中，会区分是构建版本还是发行版本，构建版本初期可以是 v0.0.0 作为前缀，发版后通过 git 从最近的 tag 获取。

    构建版本大概格式是：${baseVersion}.${buildNumber}+${buildDate}.${commitShort}
    发行版本取 ${baseVersion} 前缀
    其中还涉及容器 image tag 、artifact version ，具体实现上会有一些细微的差别。
  • 2025/8/19 12:33:00 [ 0 ] [ 0 ] 回复
  • 原木风
  • 自豪版本.默认版本.羞愧版本
    ---|--当你为发布感到自豪时进行
    ---------------|---只是正常的/可以发布的版本
    ----------------------------|----修复问题时尴尬到无法承认
  • 2025/8/19 12:00:00 [ 0 ] [ 0 ] 回复
  • 李明发
  • SemVer 啊
    格式：破坏性更新.功能性更新/修复.小修复-alpha/beta.临时热修复+构建号
    如以下是递增的：
    1.0.0-alpha.1+13
    1.0.0-beta.1+16
    1.0.0-beta.2+18
    1.0.0-1+19
    1.2.0-3+31
    ……
  • 2025/8/19 11:55:00 [ 0 ] [ 0 ] 回复
  • 张蜚
  • 我们是前后端统一版本号，从左第一位大版本重构位，第二位功能开发位，第三位功能修复位
    重构开发大版本 V1.0.0 -> V2.0.0
    从需求池提出需求 组成一个版本号 V1.1.0 -> V1.2.0 -> V1.3.0
    线上已有功能修复版本：V1.1.0 -> V1.1.1 -> V1.1.2
    确定开发需求后中途也不添加新需求，产品提新需求就迭代到后面版本中，也不影响现有版本开发。
    前后端（其他端）都是按版本号建仓库分支，发布时就认这分支版本代码打包。
    测试人员也按版本测试。
    第三位功能修复位前后端经常可能出现不统一，就按迭代最新版本编号建版本，不管那边落后都可以跳版本，最终都会归于统一。
    示例：
    第一次修复只有后端
    后端 V1.1.1
    前端 V1.1.0
    第二次修复前后端 最终统一
    后端 V1.1.2
    前端 V1.1.2
    版本编号不用在意数值
  • 2025/8/19 11:49:00 [ 0 ] [ 0 ] 回复
可能感兴趣的话题