github 新仓库你如何定义版本？

站起来没那么累，Chrome 151 都没说什么。

定义版本是仓库作者说了算，倒也轮不到用户来说三道四。facebook 归根结底也不是开发者而是公司，他用 0.x 有公司环境层面的考量，和个人开发者的做法也不是一回事。个人开发者开发也不见得就得像公司一样莫名其妙承担社会责任，人家想发什么版本号就用什么版本号。更简单的，有些个人开发者直接 r1 r2 r3 用 git 提交顺序往外发也没问题。而且公司级开源项目，用户可能会有几百万几千万，发版会更谨慎。普通个人开发者一个软件写完十年可能也就几十个人用，谁关心你版本号长什么样。

说一下 应用版本把，没上线之前肯定是 0.? ，上线就是 1.0 ，如果是改 bug 1.0.? ，加功能 1.?.0 ，如果改动较大，就是 2.x 了额

major.minor.{date}{git commit short hash}

macOS 26.8.12

release number 递增就行，按照自己的喜好来，release note 比 release number 重要。

https://semver.org/lang/zh-CN/

版本规则很简单，找一个约定俗成的就好了。我就是用的 [Semantic Versioning]( http://semver.org/lang/zh-CN/)

至于如何定义 1.0 版本，就完全是看项目作者自己如何判断项目是否处于可用的状态了。

是的，有个约定俗成的会更好，个人不喜非常随意定版本号，有时会误导人

另外，请不要将闭源软件和开源项目比较版本号

版本号不是自己定义么

唯一的约定俗成就是版本号是增加的。只要不是减少我就无所谓。管你是 semver 还是直接 12345 加着走，release note 才是有意义的东西

java 1.8 ，9 ~ 26 ， 既有开源实现也有闭源版本

属于个人开发管理/维护的项目/软件的版本号随意, 因为没有别人能约束你, 你也不需要考虑协作团队间版本同步, 规则怎么定义都是自己说了算, 你拥有最终解释权.

团队协作开发的项目/软件的版本号 都推荐按照语义化版本 semver.org 定义的明确规则执行.
但是话又说回来, 规则是死的,人是活的, 无论规则定义怎么清楚明白, 开发团队人多了就是会出现那么几个不当人的. 我这边就遇到产品大需求迭代几轮 v1/v2/v3...后, 开发的代码已经变得他妈都不认识了(已经完全不兼容旧的功能或接口了),结果就有这样的开发负责人还在这个项目版本号只递增补丁号: v1.0.1, v1.0.2, v1.0.3, ... v1.0.45 ... v1.0.67 ... v1.0.89, 他这样搞每次在旧版本需要做细微变更或出补丁时 CI 上被折腾死去活来

实际上你想怎么定就怎么定，你还能直接换成用日期的

按照 SemVer 1.0 之前（ 0.x ）表示可以随便改 API ，对兼容性没有承诺。

我觉得这是一个非常好的区分点，即 1.0 是对于 API 稳定性的一个承诺，如果还会频繁地做不兼容改动就不要升到 1.0 ；反过来如果已经有大量用户依赖，实际上已经需要考虑兼容性了，那么也应该升到 1.0 而不是继续 0.x 。