@Vegetable 好吧，就是觉得一些地方做日志，平时基本没啥问题，但日志大量被产生，收集的贼多，感觉像是在浪费磁盘。。

@wangxiaoaer 我感觉你这样的理解也是正确的

@manami 看一下 12 楼我的问题捏，对于一个微服务架构的体系下，一个服务可能看做是一个应用。但是从整体上看呢，在商业概念上可能我们是做家居和房产的两个平台，下面都是微服务架构，那哪些可以称之为应用？哪些可以称之为项目呢？

同样举例如美团，美团的外卖平台算一个项目吗？那美团的打车也算一个项目吧？一方面我是不是可以称美团外卖 app 是一个应用？另一方面打车和外卖的用户数据是从一个底层服务来的，这个服务也是一个应用是吧？

@codepm 然后再进阶一下。。我不知道你有没有了解过，不过我先问一下，有两种情况，一种是放大看，一种是缩小看。
1. 假如我们采用了微服务架构的方式，放大了看里面，每个服务是不是又是一个应用？而项目依旧是房产？
2. 假如我们又要做一个家居垂直行业平台，缩小了看，那么我们的房产还算是一个项目吗？还是从整体上来看家居+房产算是一个新的整体的项目，房产和家居成了应用的概念？

项目和应用的概念称呼是不是该随着规模的大小而变化？

@codepm 你这么一说我好像有点搞明白了。。因为我们是一个做互联网房产垂直平台的，包含了好多端如 pc、wap、小程序、APP 等，而平常我们只称呼这是“xx 端”。但其实每个都是一种应用是吧？整个房产平台就是项目吧？

/home/www

@msg7086 好吧，大概了解了，最主要的应该还是给使用的客户端、依赖端看的，那自己内部应该没必要使用了

@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 项目的好处也就这些了吧，那我是不是可以不需要使用了

@mcfog 那你说说呢，什么是语义化版本
不是为了项目发布而做的版本标记吗？并且版本标记拥有其特定的含义。那我一个网站项目也有从开发到发布的过程，我发布就不能用语义化版本吗？从而使得项目的维护者们了解正在部署的是什么版本？

如果你认为我理解有误，请指出你的理解。因为现在不是讨论你所理解的语义化版本是什么，否则继续讨论该话题