这是一个创建于 1920 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们经常看到各种 app、前端包、后端各种库、框架之类都遵循了语义化版本来进行发布的，其好处也显而易见。
但我在公司里是做传统 web 网站开发的，而且是单体应用架构。大大小小的修改一天需要上线很多次，现在都是直接在线上 git pull master 分支进行部署。 后来也在想，要不要对项目打 tag 发 release，那么用语义化版本是否可行？或者是否合适？
我个人总感觉语义化版本只适合发包、发框架、发 API 这种频率较少的项目。
 |
1
jsq2627 2019-08-27 12:04:55 +08:00
semantic versioning 对普通 web 网站收益不大
不过可以配合 git flow 规范来开发流程 |
 |
2
janus77 2019-08-27 12:10:55 +08:00 via iPhone
语义化是便于理解，如果你是项目开发者不需要理解，项目使用者才需要。
一个项目需要是对外提供服务，才会有使用者，所以操作系统平台 api 这类才需要 |
 |
3
mcfog 2019-08-27 12:36:16 +08:00
我不认为你理解什么是 semver，请看过 https://semver.org 再来聊
|
 |
4
dandankele OP @mcfog 那你说说呢，什么是语义化版本
不是为了项目发布而做的版本标记吗？并且版本标记拥有其特定的含义。那我一个网站项目也有从开发到发布的过程，我发布就不能用语义化版本吗？从而使得项目的维护者们了解正在部署的是什么版本？ 如果你认为我理解有误，请指出你的理解。因为现在不是讨论你所理解的语义化版本是什么，否则继续讨论该话题 |
|
5
dandankele OP @jsq2627 我目前所想的作用可能也就是用作团队项目规范了。
像这样： https://semantic-release.gitbook.io 由开发者遵循一套 git commit 约束，比如在 git commit 时，通过一些`fix:`、`feat:`、`docs:`、`BREAKING CHANGE`等 commit 约束来书写 commit 信息，然后再依赖 CI 对 commit 信息做分析，来决定打上语义化版本的 tag （依赖于前面所说的这些 commit 信息类型类改变 x.y.z 中的哪个数字），并且同时也能生成 release NOTE。 可能我认为语义化版本对传统 web 项目的好处也就这些了吧，那我是不是可以不需要使用了 |
|
6
jsq2627 2019-08-27 13:52:51 +08:00
@dandankele #5 是的，就我所经历的大大小小的 web 项目，强上 semver 没有太大用处。经常出现大家都偷懒只改 patch 位，major/minor 位万年不变，不过好像也没什么不良影响
|
|
7
jsq2627 2019-08-27 13:54:01 +08:00
还不如打上发布日期 tag 以便将来更方便追溯线上 bug 出现时间
|
 |
8
shawndev 2019-08-27 13:58:35 +08:00
web 版本号对用户不可见，但并不妨碍拥有自己的版本号。react 也有自己的版本号不是吗，不过考虑到发版频繁可以在 major,minor 和 patch 后面增加 build 字段。
|
 |
9
msg7086 2019-08-27 14:11:20 +08:00
「为了让这套理论运作，你必须先有定义好的公共 API。」
传统 Web 开发有「公共 API 」吗？ 而且用 semver 是为了让依赖者可以继续使用旧版的程序而不至于因为升级破坏依赖。 如果有一个爬虫能读你们去年的网页，但是你们今年更新了页面结构，还会专门保留一份去年的页面给爬虫读吗。 我觉得 3 楼说得没错，你还是没有理解 semver 到底是干啥的。 |
|
10
dandankele OP @msg7086 好吧，大概了解了，最主要的应该还是给使用的客户端、依赖端看的，那自己内部应该没必要使用了
|
 |
11
guxingke 2019-08-29 10:09:21 +08:00
Java 的二方包, version 命名规则
190829.1007 采用 release 时的时间. 人可读, 机器可比较. |
Select Language