让我们说，一个程序员团队正在Perl中使用git来托管他们的代码。现在，他们对模块的版本化存在一个小问题：
Perl::Critic和PBP都建议代码中使用RCS支持的$VERSION变量git明确建议反对在代码中使用可替换的修订号（有充分的理由）我理解为什么git不进行关键字扩展。但是，我完全理解对一些代码的修订号的需要：
use 使用标签和git describe可以轻松实现打包和测试的全球产品版本，但我仍然没有看到为单个模块引入自动版本控制的方法。
你有什么解决方案吗？
答案 0 :(得分：20)
忘掉Perl Best Practices说的话。这不是圣经，它只是建议使用RCS关键词，因为在撰写本书时，没有人在考虑其他源控制系统。您的目标永远不应该符合PBP的特定实施，而是要使PBP中的想法适应您自己的情况。请记住阅读该书的第一章。
首先，让我们来解决你的假设：
分发中的每个模块都不需要单独的版本。您只需要为每个模块文件提供与以前的发行版不同的版本。发行版中的每个模块都可以具有相同的版本，当它们执行时，它们仍然可以大于上一个发行版的版本。
为什么不手动更改快速更改模块的版本？您应该已经定义了您的代码成为人们可以使用的东西的点。在这些方面，您可以说您已经决定是否应该分发您的工作产品，无论是作为测试版还是稳定版。您可以更改版本，以便告诉人们有关您的开发的信息。当你让源代码控制系统仅仅因为你提交时就这样做了，你就失去了在开发中表示周期的机会。例如，我通常使用两个小版本。这意味着我在整理结束之前得到100个版本，我需要碰撞主要版本以恢复正确的排序顺序。如果我让VCS为我处理这个问题，这个版本空间不够。
我曾经使用RCS关键字将我的模块版本链接到他们的签入或修订号，但我从来没有真正喜欢过。在它准备好成为下一个版本之前，我对一个文件进行了很多提交，而且我不需要$VERSION仅仅因为我修复了文档错误而需要更改。版本号会大幅跳跃，因为我做了很多小改动。
现在，当我准备发布新版本时，我只需更改所有模块文件的版本。我使用ppi_version一次更改所有版本：
ppi_version change 1.23 1.24
我的所有模块文件都获得相同的$VERSION。我不需要使用$VERSION来区分它们，因为我使用普通的源代码控制功能来实现这一点。我不需要$VERSION将它绑定到特定的提交。
如果我正在努力从版本1.23开始新的发行版，我开始制作开发版本1.23_01,1.23_02，等等，但只有当我准备让人们尝试这些版本时。我在循环开始时更改版本，而不是结束。我下次发布的所有提交都已经有了他们的下一个版本。我还记下了我想要完成的循环。
当我认为这是新周期的开始时，我再次碰撞版本。当我认为我有一个稳定版本时，我将开发$VERSION更改为稳定版本，如1.23_04到1.24。每当我发布一些东西时，我也会在源代码控制中标记它。我可以很容易地看到我的主要开发点与源代码控制的对应关系。
对我来说这一切都更容易。没有任何东西与我决定使用的源代码控制有关，所以如果我改变我使用的内容，我不必重做所有内容。
答案 1 :(得分：3)
在引入不兼容的更改时，我会去手动碰撞版本，因为当然并非每次更改都能证明这一点。
您可能还想查看filter属性的“gitattributes”联机帮助页 - 也许您会想要引入自己的过滤器来根据“git describe”输出进行替换自动。
答案 2 :(得分：3)
您使用什么来构建Perl模块？
Linux内核和Git项目本身使用的解决方案是替换“++ VERSION ++”（或“++ PROJECT_VERSION ++”或“@@ PROJECT_VERSION @@”）占位符 由构建系统，在这种情况下由Makefile。 （在C中的文件中，通过定义“PROJECT_VERSION”预处理器常量，通过传递给编译器的“-DPROJECT_VERSION=$(PROJECT_VERSION)”选项来完成。在您的情况下，可能类似于Module::Install，Module::Build或ExtUtils::MakeMaker。
Git和Linux内核都使用了GIT-VERSION-GEN脚本：
git describe version（或VERSION或GIT-VERSION-FILE）文件，cb572206，即提交v1.6.4.4）。我希望这会对你有所帮助。
答案 3 :(得分：0)
一些非常懒的东西怎么样只是有点混乱：
你可以为git-add写一个小包装器。在实际调用git-add之前，包装器会在模块中的某个位置轻推一个版本号，可以使用简单的正则表达式找到它。
更新
我目前没有使用类似的东西，但我正在认真考虑它。
我目前的推理：
优点：
缺点：
git add .的懒惰开发者会轻推他未触及的文件的版本号。