原文自博客发布平台medium，作者为 better-programming 的 Tushar Sadana，传送门
实现语义化版本控制，便于每个依赖能够保持一致。
或许你会想在软件、游戏或者应用中的号码，像 11.2.3或者10.4.3.2arm64表示什么意思。
它们其实是代表应用中当前的或者曾经的版本。此外，对于同一个版本，也会被区分为不同的类型。
版本控制的原因
但是为什么我们需要控制版本呢？这有必要吗？
最有可能的是，随着应用的升级，项目中的依赖的数量也会随之增长。依赖越多，进行管理的难度也就越大。
有时，你会发现如果不打破那些因紧联系而难以升级的事项的关系时，应用是很难去做升级的。
除此之外另一点，是关系太松散。有些依赖是为未来的考而不是当前的情况服务的。这种情况通常被称为依赖地狱。
一个简单的解决方法是使用一组通用的规则来开始正确地处理版本控制，这有助于所有依赖保持一致。这种方法叫做语义化版本控制。
语义化版本控制
语义化版本控制有明确的规则需要被遵循，而我们可以在这个网站中找到这些规则。
我们通常将版本定义格式为 X.Y.Z（Major.Minor.Patch）。
- bug 修复不会影响 API 中 patch 版本的增加
- 向下兼容添加或者更改的 API 会导致 minor 版本的增加
- 向下不兼容的 API 会导致 major 版本的增加
你应该去阅读相关的规则以便知道什么时候应该或者什么时候不应该去更改版本的 Major.Minor.Patch。
但是，每次这样更新版本号数字难道不觉得很乏味吗？每次都会有一些需要被更新的文件而且你还需要记住什么时候做了这个事情。
这听起来一点儿都不有趣。如果我告诉你有更好的方法你会怎么做？
这就到 bump2version 出现的时候了。这个 github 开源项目也许是用作版本控制的最好的 python 库了。用它有多难？
pip install --upgrade bump2version当你安装完成后，我们需要创建一个 bump 配置文件，以便脚本可以以我们的方式来运行。
假设我们有一个目录叫 project_xyz 并且在里面有另外两个目录：Backend 和 Frontend。
再假设一下，Backend 上包含一个文件 setup.py 以及 Frontend 上包含一个文件 build.sh。每个文件都包含 Backend 和 Frontend 的版本。这些版本可能相同也可能不同，这取决于你的版本增加方式（遵循规则）。
我们创建一个名为 .bumpversion.cfg 的文件（注意是隐藏文件）。这个文件是用于定义哪里以及哪个版本需要被更新。
我们将其定义为以下内容：
[bumpversion]
current_version = 0.1.0
commit = True
tag = True
[bumpversion:file:config.ini]
search = version="{current_version}"
replace = version="{new_version}"
[bumpversion:file:Backend/setup.py]
search = version="{current_version}"
replace = version="{new_version}"
[bumpversion:file:Frontend/build.sh]
search = VERSION="{current_version}"
replace = VERSION="{new_version}"当你需要更改整个项目的版本的时候，你可以在 project_xyz 的根目录中运行这些命令，然后它就会自动更新所有文件。
像这样：
bump2version major // 0.1.0 --> 1.0.0
bump2version minor // 0.1.0 --> 0.2.0
bump2version patch // 0.1.0 --> 0.1.1注意到，下面的所有文件都会包含这一行：
version = 0.1.0 //or the version updated但是，当你想对单个文件进行这个操作的话（例如你仅仅更新了 Backend 并且你只想更新它的版本），你可以这样做：
bump2version minor Backend/setup.py这还有一种方式来更新特定的版本：
to go from 0.5.1 directly to 0.6.1: //将0.5.1更新为0.6.1
bump2version --current-version 0.5.1 --new-version 0.6.1 patch Backend/setup.py当然，也有一种方法来添加版本的描述信息：
bump2version --message 'Build {$BUILD_NUMBER}: {new_version}' patch当你为每一个 git 的提交创建信息的时候，这就是我所说离 git 的原子推送更进一步了。
希望你喜欢这篇文章，感谢你的阅读！