如何避免在源代码中保留版本号？

Question

到目前为止，我们将 Python 源代码的版本号保存在 setup.py 中。

每次成功运行 ci 后，此版本都会增加。

这意味着中央库的版本每天增加数倍。

由于版本号存储在 git repo 的一个文件中，因此版本号的每次增加都是一次新的提交。

这意味着大约 50% 的提交不是由人类完成的，而是由 CI 完成的。

我有一种感觉，我们走错了路。也许将版本号保留在 ci 中不是一个好的解决方案。

我们如何避免只会增加版本号的“无用”CI 提交？

如何避免在源代码中保留版本号？

更新

几年来，我们没有手动发布。我们没有像 MAJOR.MINOR 这样的版本控制方案。我们过去没有错过这一点。我知道这不适用于所有环境。但它适用于我当前的环境。

我们有一个看起来像这样的版本号：YEAR.MONTH.X

这意味着每个通过 CI 的提交都是一个新版本。

阅读答案后，我意识到：我需要问自己：我到底有没有版本号？我想不是。我有一个内部版本号。在这种情况下不需要更多。

（感谢您的投票。在问这个问题之前，我确信这个问题会被关闭，因为人们会认为它“不清楚”或“太宽泛”）

Answer 1

在源代码中保留一个版本号是一种常见的做法，这没有错。您需要将 CI 过程与常规构建、发布发布和发布部署分开。定期构建：每天甚至在每次提交后运行，可以包括静态代码分析和自动测试，检查代码是否可以构建。常规构建不应更改版本号。发布发布：只能由发布经理的显式手动操作触发。触发操作可以是用新版本号标记提交，新合并到发布分支，或者只是更改保存在特殊文件（例如pom.xml）中的版本号的提交。例如，请参考 git flow。发布发布分配新版本号（自动或手动），必要时将其提交到源代码中，使用新版本构建二进制包并将其上传到二进制包存储库（例如 Nexus、devpi、本地 APT 存储库、Docker注册表等）。发布部署：另一个手动触发的操作，从包存储库中获取准备好的二进制包并将其安装到目标环境（开发、QA/UAT/暂存、金丝雀部署的生产部分或整个生产环境）。

Answer 2

前提：我假设这些是讨论解决方案的前提。当前版本号保存在 git-tracked 源文件中，但您可以摆脱它。没有人手动管理版本号，也没有触发发布程序，其中包括：（a）增加版本号，（b）从源构建和（c）将构建结果存储在某处。这些由 CI 处理，并且应该保持这种状态。解决方案：CI 不是写入源文件并创建新提交，而是简单地标记通过 CI 检查的特定提交，然后将标记推送到远程仓库。构建脚本应该读取当前 HEAD 提交的标签，并将其用作发布版本的版本号。或者，您可能希望使用git filter-branch重写现有的 git repo 历史记录，标记以前的版本提交以保持一致性，删除并停止跟踪版本号源 cile，然后摆脱那些 CI 提交。

Answer 3

我认为你应该使用 git flow。并创建一个master分支和一个develop分支。每次 CI 检查开发时，版本号保持不变。每次你创建一个版本，例如将开发合并到主，你可以通过 CI 增加版本号。或者我遗漏了什么，但在我看来，没有理由每次 ci 运行时都会增加版本号。因此，总而言之，您最好考虑何时“发布”对新版本的更改！！