如题，v1.0.0
想看看有没普遍认可的版本号管理规则，基本上安卓和 iOS 有版本号管理，后端和前端算是没有，当然最好的做法也是需要。
各位的公司是怎么制定版本号的？
想看看有没普遍认可的版本号管理规则，基本上安卓和 iOS 有版本号管理，后端和前端算是没有，当然最好的做法也是需要。
各位的公司是怎么制定版本号的？
 |
1
huangzhiyia 11 天前 via iPhone  6
大破坏.小破坏.修复破坏
|
 |
2
wKong753900 OP 搜到之前有篇文章： https://semver.org/lang/zh-CN/ （语义化版本）
|
 |
3
lnbiuc 11 天前
必须更新 不更新不能用.新功能/大 BUG.小 BUG
|
 |
4
cabudad 11 天前
我们是 MMPD ，不兼容的新功能更新主版本号，兼容的新功能更新次版本号，补丁更新修订版本号
|
|
5
wKong753900 OP @cabudad 这个可以，我们有点类似
|
 |
6
gmfan 11 天前
无所谓，直接加一就好了，还省得动脑子
|
 |
7
xiuming 11 天前 2
我们是前后端统一版本号，从左第一位大版本重构位，第二位功能开发位，第三位功能修复位
重构开发大版本 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 版本编号不用在意数值 |
 |
8
w568w 11 天前 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 …… |
|
9
wKong753900 OP @xiuming 看起来挺不错的，不过真的能做到确定开发需求后中途也不添加新需求吗？产品提的新需求优先级最高呢？
|
 |
10
rocmax 11 天前 via Android
分支跟随 feature ，发版的时候打版本 tag
|
 |
11
chen05 11 天前 3
自豪版本.默认版本.羞愧版本
---|--当你为发布感到自豪时进行 ---------------|---只是正常的/可以发布的版本 ----------------------------|----修复问题时尴尬到无法承认 |
 |
12
TigerK 11 天前
还是使用日期吧，比较容意理解，比如 v2025.08.16
|
|
13
wKong753900 OP @TigerK 哈哈，简单粗暴，就是不够优雅
|
 |
14
Wataru 11 天前 via iPhone
@wKong753900 个人感觉最易懂的才是最优雅的，搞得人看不懂的看起来高大上实则没意义
|
 |
15
ShineyWang 11 天前 via Android
@wKong753900 语义版本有对应的 git 插件
gitversion 可以自动生成版本 |
|
16
xiuming 11 天前
@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 |
|
17
wKong753900 OP @xiuming 这么规范
|
|
18
wKong753900 OP @huangzhiyia 哈哈
|
 |
19
angrylid 11 天前
理想中是 SemVer
实际上是 1.0.z z++ |
 |
20
MYDB 11 天前
a.b.c
a 0~∞ b 0~9 c 0~99 |
 |
22
ne6rd 11 天前
版本号你们觉得需要根据项目类型来区分策略吗？
客户端，库，API 感觉并不能一概而论 |
 |
23
COW 11 天前
版本号本身会使用语义化版本 semver2 ，实际使用中，会区分是构建版本还是发行版本，构建版本初期可以是 v0.0.0 作为前缀，发版后通过 git 从最近的 tag 获取。
构建版本大概格式是：${baseVersion}.${buildNumber}+${buildDate}.${commitShort} 发行版本取 ${baseVersion} 前缀 其中还涉及容器 image tag 、artifact version ，具体实现上会有一些细微的差别。 |
|
24
wKong753900 OP @COW 感觉可以
|
 |
25
kugua233 10 天前
我真的牛的不行，正常修复 bug ，偷偷补锅
|
 |
26
bowencool 10 天前
但凡你发帖前 Google 一下或 AI 一下...
|
 |
27
KongLiu 10 天前
前后端的版本号就是日期，jenkins 根据时间打包，然后推到 Docker
|
 |
28
14 10 天前 1
更新频繁的我都使用日期作为版本
|
 |
29
OneLiteCore 10 天前
[大功能更新/大规模重构/第一个正式版] + [功能更新] + [小修复/小优化] ，基本是按照这个路数来的
|
 |
30
agagega 10 天前
能持续使用的就两种：一种是前面提到的语义化版本，大版本是巨大的破坏式改动，中版本表示有兼容性改变，小版本只修 bug 保持兼容；另一种是去 tmd 版本，只用年月日做版本，不考虑兼容性，给我对齐最新的就行
|
 |
31
flyqie 10 天前 via Android
不同公司不同项目区别很大。
需求比较多变的话，语义化版本用着用着就混乱了 |
 |
32
F4NNIU 10 天前
尽最大可能的严格遵循《语义化版本规范》 v2.0
|
 |
33
hwdq0012 10 天前 via iPhone
三个数字的版本号好像是微软提出的 msdn 有个很详细的文档
|
 |
34
harlen 10 天前
1.0 1.1 2.0 2.1 3.0 3.1 2.2 然后 2.3 的版本 比 3.x 的版本还新
|
 |
35
realpg PRO 第一位, 主要版本, 大版本带来的是整体的 API 组重构, 或者完全不一样的基础架构, 或者战略意义的新功能集
参考那种两三年变动一次大版本的常见 app 但是不固定的按时间跨度增加 第一位的变动, 重新走软件著作权版本号流程, 第一位写在软著里面. 第二位, 涉及必须强制更新的, 或者修改既有的大模块的大部分东西, 或者新增重大模块, 删除重大模块 第三位, 每次更新都变 加几看情况 如果公司预期版本号最后一位支持 4-5 位数字 则最后一位每次 commit 都+1 或者加更大的步长, 然后每次有冲突的合并再+1, 没冲突的合并就以最后一次 |
 |
36
Tinyang 9 天前
v182.25.9.29 我们组的实践是当前 sprint 号+release 时间+(sp ，一些特殊后缀)
|
 |
37
wangtian2020 9 天前
后端小老弟我不管他，前端我自己直接显示成 build@20250818 了
define: { __BUILD_DATE__: dayjs().format(`YYYYMMDD`), } |
 |
38
viayie 8 天前
大型 C 项目，拆分出若干个子工程作为依赖，给他们做了语义化版本，但都不用，无奈最后做成了下面这种形式：
$ echo $(git describe --tags)-$(date +%Y%m%d) 1.0.0-3245-gd1521e1d60-20250819 |
Select Language