我很想知道你是如何处理新版本问题的碰撞版本号的。
如何处理相关文件中的版本号，如手册页等。
该软件使用gnu工具链构建，因此autoconf，automake等可用并用于应用程序的版本号。这样可以重复使用这些信息。
git用作vcs。
一种可能性是在Makefile.am中引入一个额外的，新的目标，它使用sed / awk来替换所有相关文件中的版本号和日期。该目标可以在开发新版本时（在分支之后）调用一次。
然后当人们执行项目的 git clone 或者发布tarball时，项目可以使用正确的信息构建。当然，在开始开发新版本时，必须记住运行此make目标。
另一个选择是使用dist目标的钩子进行sed / awk替换。但是这会使项目的git存储库处于没有正确版本号与关联文件关联的状态。
我更喜欢第一个解决方案，因为它还会在git历史记录中记录正确的版本号。
在进行sed / awk替换时，您更喜欢“在文件中”或使用autoconf / automake工具中的模板文件。我在两种方法中都看到了优点和缺点。
如何处理相关文件的版本控制。你是否在开发阶段开始时更改它们，是否在发货之前更改它们，是否进行了更换，或者您更喜欢使用模板？
THX。
答案 0 :(得分：10)
现在常见的解决方案是使用m4_esyscmd参数调用AC_INIT以从git生成VERSION。例如，autoconf的configure.ac包含以下行：
AC_INIT([GNU Autoconf],
m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[bug-autoconf@gnu.org])
其中build-aux / git-version-gen是一个简单的脚本，它调用'git describe'来生成版本号。 （见gnulib）
这种方法有缺点，但它可能有效。
答案 1 :(得分：6)
我认为执行此操作的标准方法是使用Git的钩子系统和m4或sed / awk按照您的建议进行搜索/替换。您只需要在每个文件的注释中添加一个特殊标记（可能在标题中）。
以下是githooks的参考资料，以下是解决同一问题的人写的几页：
这两个都依赖于将版本号存储在源树中的某个文件中。
我还遇到了一个名为0release的名单，声称可自动发布版本（并设置版本号）。
最后，关于版本号，这可以在其他几个问题中解决：
答案 2 :(得分：1)
我们使用经典的major.minor.patch系统，它被应用于释放候选者作为'标签'，我们有一个脚本，它将提交标记为版本号，而不是使用git'标记对象'。所有版本编号都是“手动”完成的。它运作得相当好，因为 版本号由“发布到暂存”脚本创建，后者在开发过程中稍后进行。我们不打扰使用任何git钩子，因为我们真的不需要，如果提交没有离开开发环境，那么除了内部SHA代码之外它不需要id。
我们尝试强制执行每个“补丁”版本必须与具有相同主要，次要标记的其他版本二进制兼容。
这样，带标签的任何东西都应至少构建，但它可能或很可能不适用于规范。
一个改进是让QA部门在“QA批准”的任何内容上创建一个签名标签对象，但现在我们依赖其他文书工作。