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

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

这意味着中央库的版本每天都会增加几次。

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

这意味着大约50％的提交不是由人做出的，而是由CI做出的。

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

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

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

更新资料

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

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

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

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

（感谢您的投票。在问这个问题之前，我已经确定这个问题将结束，因为人们会认为这是“不清楚”或“范围太广”）

我们的团队现在正在发布火车部署模型（http://thinking-in-code.blogspot.com/2010/07/train-model-of-software-development.html），我们需要工具或方法来管理如何我们合并 Pull 请求并构建新版本。

注意：我将使用 Git 术语来解释问题

通过发布序列部署模型，发布按固定的时间表进行，并且功能固定到特定的版本。但此模型的核心思想是，如果某个功能不完整或特别不存在错误，则该功能不会在即将发布的版本中采用，而是计划在以后的版本中使用。

考虑到这一点，我们需要一些方法来管理 Pull 请求并发布以下方面的版本：

1. 可以使用所有功能分支进行构建，以便可以对该构建进行测试（QA）。我们实际上不想将其合并到我们的开发或发布分支中。（为什么？下一点会讨论）

2. 因此，如果某个功能不是零错误（无错误），我们会希望删除该功能。因此，我们实际上只会合并零错误的功能并创建新的发布版本。这样，一个功能就可以很容易地被删除。就发布列车术语而言，该功能不会登上发布列车。

我们的想法：

假设master包含已发布的代码。现在在其之上创建了特征分支 F1、F2、F3。

1. 我们的自动化设置将按时间顺序将这些功能分支（来自具有“已批准”状态的拉取请求）合并到从主分支中删除的临时分支中，并且设置将从该临时分支创建用于 QA 测试的构建。（合并临时分支不会关闭PR）

2. 现在，如果只有功能 F1 和 F3 在零错误日期没有错误，那么 F1 和 F3 的 PR 将被手动合并到 master 中，并且将从 master 创建最终发布版本。

（注：对于第1点，如果出现合并冲突，则由各个分支的开发人员解决。）

有没有 Jenkins 插件或任何其他工具可以帮助我们实现上述目标。请分享一些对此的想法，并提出处理此问题的更好方法。