如何用git自动更新perl模块的$version?

忘记什么 Perl Best Practices 说。这不是圣经,它只是建议使用rcs关键字,因为在编写时,没有人想到其他的源代码控制系统。您的目标不应该是遵守PBP的特定实现,而是适应 思想 在你自己的情况下。记得读那本书的第一章。

首先,让我们修正您的假设:

1. 对于发行版中的每个模块,不需要单独的版本。您只需要为每个模块文件提供不同于以前发行版的版本。发行版中的每个模块都可以具有相同的版本,当它们具有相同的版本时,它们仍然可以大于上一个发行版的版本。

2. 为什么不手动更改快速更改模块的版本?您应该已经定义了代码成为人们可以使用的东西的点。在这一点上,您做了一些事情来说明您已经做出了决定,您的工作产品应该作为一个测试或稳定的版本发布。您更改版本是为了告诉人们关于您的开发的一些事情。当您仅仅因为提交而让源代码管理系统这样做时,您将失去在开发中表示周期的机会。例如,我通常使用两处小版本。这意味着在整理结束之前,我会得到100个版本,我需要修改主要版本以恢复正确的排序顺序。如果我让风投帮我处理这个,那就没有足够的版本空间了。

我曾经使用rcs关键字将我的模块版本链接到它们的签入或修订号,但我从来没有真正喜欢过。在一个文件准备好成为下一个版本之前,我对它进行了很多提交,我不需要 $VERSION 只是因为我修正了文档的错误。因为我做了很多小改动,所以版本号会有很大的飞跃。

现在,当我准备发布一个新的发行版时,我只需更改所有模块文件的版本。我用 ppi_version 一次更改所有版本:

ppi_version change 1.23 1.24

我所有的模块文件都是一样的 美元版本 . 我不需要用 $版本 将它们分开,因为我使用普通的源代码管理功能来做到这一点。我不需要 美元版本 将其与特定的提交绑定。

如果我正致力于从1.23版开始开发新的发行版,我就开始开发1.23_01、1.23_02等版本,但只有当我准备好让人们尝试这些版本时。我在循环开始时更改版本,而不是在循环结束时更改。在下一个版本之前,我所有的提交都已经有了下一个版本。我也会记录下我希望这个循环能完成什么。

当我认为这是一个新周期的开始时,我又碰到了这个版本。当我认为我有一个稳定的版本时,我改变了开发 美元版本 稳定的,比如1.23_04到1.24。每当我释放一些东西时,我也会在源代码管理中标记它。我可以很容易地看到我的主要开发点在哪里与源代码管理一致。

这样对我来说一切都容易多了。没有任何东西与我决定使用的源代码管理相关联,所以如果我更改了我使用的内容,就不必重做任何事情。

当引入不兼容的更改时,我会选择手动转发版本,因为,当然不是每个更改都能证明转发是正确的。

您可能还想签出' gitattributes ' filter 属性__ git describe '自动输出。

您使用什么来构建Perl模块?

Linux内核和Git项目本身使用的解决方案是替换“++版本+”(或“++项目版本++”,或“@@project\u版本@@”)。 占位符 通过构建系统 在这种情况下,通过makefile。(在C中的文件中,通过定义“project_version”预处理器常量,通过' -DPROJECT_VERSION=$(PROJECT_VERSION) '选项传递给编译器)。在你的情况下,可能是 Module::Install , Module::Build 或 ExtUtils::MakeMaker .

这两个git-ans-linux内核都使用 GIT-VERSION-GEN 脚本:

1. 使用 git describe 如果项目是从Git存储库中构建的,
2. 退缩 version (或) VERSION 或 GIT-VERSION-FILE )文件,如果从快照生成(创建快照/存档时创建此文件),
3. 最后回到预先定义的版本号,这个版本号在commit中更新,它标记新的发布版本(例如 cb572206 在Git存储库中提交,也称为提交 v1.6.4.4 )

我希望这对你有帮助。

如果你真的很懒,只是有点乱七八糟的话,你觉得怎么样?

你可以写一个小包装 git-add . 在打电话之前 Git添加 包装器将在模块中的某个位置推送一个版本号,在该位置可以使用简单的regex找到它。

更新:

我目前并没有自己用这种东西,但我正在认真考虑。

我目前的推理:

• 与cvs或subversion不同,git对版本号或修订号一无所知。
• 筛选器驱动程序需要有不同的信息源才能插入版本号,并且此源必须在任何相关开发人员的计算机上可用。
• 因此,版本号的最佳来源是版本文件本身。
• 为了使文件本身可以用作下一个版本号的源,版本号需要是其相应的git blob的一部分。

效益:

• 这是自动的,因为它得到,没有办法忘记更新您的版本号。
• 从cvs/svn到git的平滑过渡。每次提交都会引入一个新版本。

缺点:

• 总是这么做的懒惰的开发人员 git add . 将推送他未接触的文件的版本号。
• 似乎没有一种方法来强制使用包装器脚本。