问题描述
在开发过程中遇到了语义化版本控制的问题。他的项目结构如下：
SOME_MONOREPO, managed by lerna
- package-a
- package-b - depends on package-a, package-c
- package-c - is currently private, so not published as npm package. When package-b builds, it accesses package-c directly via symlink. As we move forward, we'll transition this to published packages like package-a.
ANOTHER_PROJECT
- package-foo
- depends on SOME_MONOREPO.package-a
现在，他正在对package-a进行一些工作，这可能是一个主要的、次要的或补丁的更改。
有几种可能的开发流程：
1. 最简单的情况：只对package-a进行工作，编写测试，然后在准备好后进行版本升级并推送到主分支。
2. 在对package-a进行工作的同时，还更新package-b以适应破坏性的更改/使用新功能。在这种情况下，代码不一定需要进行版本升级，因为lerna的符号链接仍然可以让package-b访问package-a的代码。
3. 同时还在package-foo上进行工作。在这种情况下，需要发布到npm以访问代码。
因此，用户认为在这里需要进行夜间/不稳定/预发布构建。也就是说，他在package-a上构建了一些功能，构建了一个不稳定的构件，然后package-foo可以使用它，看看它是否适合使用。
但是，最终还是需要决定这是一个主要的、次要的还是补丁更新。
问题是 – 这应该在什么时候发生？开发人员在每次更改时是否应该在第一个PR中决定版本升级？（并且它不是一个发布PR，CI会自动发布带有“不稳定”附录的版本，当它发布时，不稳定的附录将被删除）。如果另一个开发人员同时在同一个包上工作怎么办？
是否有一种方法可以在正式发布之前不考虑版本升级？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
版本升级应该在每次构建时进行。等到正式发布并将所有内容发布为1.0.0是一个选择，但你仍然应该知道你在alpha/beta中使用的构建版本。
最终，开发人员必须确定是否需要进行主要版本的增加。只有在引入了破坏性更改时才应该进行主要版本的升级。
对于常规构建，一种常见的做法是让你的CI工具递增“补丁版本”号或版本号的X.X.Patch部分。这样，你的版本控制与构建过程相关联，有助于开发和测试过程。如果你选择只进行夜间构建，你可以让你的CI工具递增这个数字，这样你和其他开发人员就知道他们正在使用的包的版本号。
NPM已经发布了一份关于如何处理语义化版本控制的指南。
方案2
使用脚本或工具来管理版本号可能会增加复杂性，并且需要确保多个开发人员之间的版本控制一致。
另一种方法是编写脚本或使用工具来控制版本号。你可以使用lerna等工具来管理你的monorepo，并自动处理版本号的递增。
以下是一个示例的lerna.json配置文件：
{
"version": "independent",
"npmClient": "npm",
"command": {
"publish": {
"allowBranch": ["master"],
"message": "chore(release): publish",
"registry": "https://registry.npmjs.org/"
}
}
}
在上面的示例中，我们将version设置为independent，这意味着每个包都可以独立地进行版本控制。这样，每次构建时，lerna将自动递增每个包的版本号。
请注意，使用脚本或工具来管理版本号可能会增加复杂性，并且需要确保多个开发人员之间的版本控制一致。
以上是关于在开发中如何处理语义化版本控制的一些建议。根据你的具体情况和团队的需求，选择适合你的方法。
希望对你有所帮助！