目前我看到大量开发者，从建仓库开始，就是 1.0 版，特别是国内开发者。而国外开发者一般在没达到生产环境前都不会到 1.0 版，有的仓库好几年了还是零点几，比如 https://github.com/facebook/lexical 。大家到底是怎么定义这个版本的呢？看到有人一次提交就是一个大版本，几天就是几个大版本，也是很奇妙了。。。
 |
1
greatghoul 18h 57m ago
站起来没那么累，Chrome 151 都没说什么。
|
 |
2
msg7086 18h 40m ago
定义版本是仓库作者说了算，倒也轮不到用户来说三道四。facebook 归根结底也不是开发者而是公司，他用 0.x 有公司环境层面的考量，和个人开发者的做法也不是一回事。个人开发者开发也不见得就得像公司一样莫名其妙承担社会责任，人家想发什么版本号就用什么版本号。更简单的，有些个人开发者直接 r1 r2 r3 用 git 提交顺序往外发也没问题。而且公司级开源项目，用户可能会有几百万几千万，发版会更谨慎。普通个人开发者一个软件写完十年可能也就几十个人用，谁关心你版本号长什么样。
|
 |
3
ajaxfunction 18h 15m ago
说一下 应用版本把，没上线之前肯定是 0.? ，上线就是 1.0 ，如果是改 bug 1.0.? ，加功能 1.?.0 ，如果改动较大，就是 2.x 了额
|
 |
4
capric 18h 13m ago
major.minor.{date}{git commit short hash}
|
 |
5
IlIl 18h 8m ago
macOS 26.8.12
|
 |
6
darkengine 17h 43m ago
release number 递增就行，按照自己的喜好来，release note 比 release number 重要。
|
 |
7
artiga033 17h 29m ago via Android
|
 |
8
94 17h 13m ago
版本规则很简单，找一个约定俗成的就好了。我就是用的 [Semantic Versioning]( http://semver.org/lang/zh-CN/)
至于如何定义 1.0 版本，就完全是看项目作者自己如何判断项目是否处于可用的状态了。 |
 |
9
Gomoku2024 OP 是的，有个约定俗成的会更好，个人不喜非常随意定版本号，有时会误导人
|
|
10
Gomoku2024 OP 另外，请不要将闭源软件和开源项目比较版本号
|
 |
11
letwewell 13h 22m ago
版本号不是自己定义么
|
 |
12
haukuen 12h 21m ago
唯一的约定俗成就是版本号是增加的。只要不是减少我就无所谓。管你是 semver 还是直接 12345 加着走，release note 才是有意义的东西
|
 |
13
python35 11h 41m ago
java 1.8 ，9 ~ 26 ， 既有开源实现也有闭源版本
|
 |
14
yougg 11h 41m ago
属于个人开发管理/维护的项目/软件的版本号随意, 因为没有别人能约束你, 你也不需要考虑协作团队间版本同步, 规则怎么定义都是自己说了算, 你拥有最终解释权.
团队协作开发的项目/软件的版本号 都推荐按照语义化版本 semver.org 定义的明确规则执行. 但是话又说回来, 规则是死的,人是活的, 无论规则定义怎么清楚明白, 开发团队人多了就是会出现那么几个不当人的. 我这边就遇到产品大需求迭代几轮 v1/v2/v3...后, 开发的代码已经变得他妈都不认识了(已经完全不兼容旧的功能或接口了),结果就有这样的开发负责人还在这个项目版本号只递增补丁号: v1.0.1, v1.0.2, v1.0.3, ... v1.0.45 ... v1.0.67 ... v1.0.89, 他这样搞每次在旧版本需要做细微变更或出补丁时 CI 上被折腾死去活来 |
 |
15
renmu 11h 35m ago via Android
实际上你想怎么定就怎么定，你还能直接换成用日期的
|
 |
16
jybox 11h 7m ago
按照 SemVer 1.0 之前（ 0.x ）表示可以随便改 API ，对兼容性没有承诺。
我觉得这是一个非常好的区分点，即 1.0 是对于 API 稳定性的一个承诺，如果还会频繁地做不兼容改动就不要升到 1.0 ；反过来如果已经有大量用户依赖，实际上已经需要考虑兼容性了，那么也应该升到 1.0 而不是继续 0.x 。 |
Select Language