闲聊一个话题， v1.0.0，各位公司对版本号有没什么好的管理方式，还是每次新版就增加上去？

大破坏.小破坏.修复破坏

搜到之前有篇文章： https://semver.org/lang/zh-CN/ （语义化版本）

必须更新 不更新不能用.新功能/大 BUG.小 BUG

我们是 MMPD ，不兼容的新功能更新主版本号，兼容的新功能更新次版本号，补丁更新修订版本号

@cabudad 这个可以，我们有点类似

无所谓，直接加一就好了，还省得动脑子

我们是前后端统一版本号，从左第一位大版本重构位，第二位功能开发位，第三位功能修复位
重构开发大版本 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

版本编号不用在意数值

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
……

@xiuming 看起来挺不错的，不过真的能做到确定开发需求后中途也不添加新需求吗？产品提的新需求优先级最高呢？

分支跟随 feature ，发版的时候打版本 tag

自豪版本.默认版本.羞愧版本

---|--当你为发布感到自豪时进行
---------------|---只是正常的/可以发布的版本
----------------------------|----修复问题时尴尬到无法承认

还是使用日期吧，比较容意理解，比如 v2025.08.16

@TigerK 哈哈，简单粗暴，就是不够优雅

@wKong753900 个人感觉最易懂的才是最优雅的，搞得人看不懂的看起来高大上实则没意义

@wKong753900 语义版本有对应的 git 插件
gitversion 可以自动生成版本

@wKong753900 有流程在这 需求都是从产品的需求池提出来产品经理拍板的组成新版本 各小组评审过的 平时产品经理乱来代价就变高了 不排除老板和产品经理突然的紧急新需求

2.1.0 正在开发 需求 1 需求 2 分配（生产力 1 生产力 2 生产力 3 ）
突然市场上微信做出红包了 新生成紧急 需求 3 红包玩法
2.2.0 待开发 需求 3

产品需要召开项目全组员进行变更 原 2.1.0 变更为 2.3.0

生产力不足我们一般暂停版本 2.1.0
2.2.0 分配（生产力 1 生产力 2 生产力 3 ） 开发 需求 3

生产力充足我们两个版本一起开发
2.2.0 分配（生产力 1 生产力 2 ） 开发 紧急需求 3
2.3.0 分配（生产力 3 ） 开发 需求 1 需求 2

2.2.0 上线后 2.2.0 分支代码合并 2.3.0 生产力释放 又可以全力开发版本 2.3.0
2.3.0 分配（生产力 1 生产力 2 生产力 3 ） 开发 需求 1 需求 2

@xiuming 这么规范

@huangzhiyia 哈哈

理想中是 SemVer
实际上是 1.0.z z++

a.b.c
a 0~∞
b 0~9
c 0~99

@chen05
我早的项目就是这么发版的
然后发现永远卡在 0.x.x ......

版本号你们觉得需要根据项目类型来区分策略吗？
客户端，库，API 感觉并不能一概而论

版本号本身会使用语义化版本 semver2 ，实际使用中，会区分是构建版本还是发行版本，构建版本初期可以是 v0.0.0 作为前缀，发版后通过 git 从最近的 tag 获取。

构建版本大概格式是：${baseVersion}.${buildNumber}+${buildDate}.${commitShort}
发行版本取 ${baseVersion} 前缀

其中还涉及容器 image tag 、artifact version ，具体实现上会有一些细微的差别。

@COW 感觉可以

我真的牛的不行，正常修复 bug ，偷偷补锅

但凡你发帖前 Google 一下或 AI 一下...

前后端的版本号就是日期，jenkins 根据时间打包，然后推到 Docker

更新频繁的我都使用日期作为版本

[大功能更新/大规模重构/第一个正式版] + [功能更新] + [小修复/小优化] ，基本是按照这个路数来的

能持续使用的就两种：一种是前面提到的语义化版本，大版本是巨大的破坏式改动，中版本表示有兼容性改变，小版本只修 bug 保持兼容；另一种是去 tmd 版本，只用年月日做版本，不考虑兼容性，给我对齐最新的就行

不同公司不同项目区别很大。

需求比较多变的话，语义化版本用着用着就混乱了

尽最大可能的严格遵循《语义化版本规范》 v2.0

三个数字的版本号好像是微软提出的 msdn 有个很详细的文档

1.0 1.1 2.0 2.1 3.0 3.1 2.2 然后 2.3 的版本 比 3.x 的版本还新

第一位, 主要版本, 大版本带来的是整体的 API 组重构, 或者完全不一样的基础架构, 或者战略意义的新功能集
参考那种两三年变动一次大版本的常见 app 但是不固定的按时间跨度增加

第一位的变动, 重新走软件著作权版本号流程, 第一位写在软著里面.

第二位, 涉及必须强制更新的, 或者修改既有的大模块的大部分东西, 或者新增重大模块, 删除重大模块

第三位, 每次更新都变 加几看情况 如果公司预期版本号最后一位支持 4-5 位数字 则最后一位每次 commit 都+1 或者加更大的步长, 然后每次有冲突的合并再+1, 没冲突的合并就以最后一次

v182.25.9.29 我们组的实践是当前 sprint 号+release 时间+(sp ，一些特殊后缀)

后端小老弟我不管他，前端我自己直接显示成 build@20250818 了
define: {
__BUILD_DATE__: dayjs().format(`YYYYMMDD`),
}

大型 C 项目，拆分出若干个子工程作为依赖，给他们做了语义化版本，但都不用，无奈最后做成了下面这种形式：

$ echo $(git describe --tags)-$(date +%Y%m%d)
1.0.0-3245-gd1521e1d60-20250819