在关联文件中更改新版本的版本号（文档）
我很想知道你们如何处理新版本问题的碰撞版本号。
如何处理相关文件（如手册页等）中的版本号。
该软件是使用 gnu 工具链构建的，因此 autoconf、automake 等可用并用于应用程序的版本号。 这样信息就可以被重用。
git 被用作 vcs。
一种可能性是在 Makefile.am 中引入一个额外的新目标，该目标执行 sed/awk 来替换所有关联文件中的版本号和日期。 该目标可以在新版本开发开始时（在分支之后）调用一次。
然后，当人们对项目进行 git 克隆或发布 tarball 完成时，项目就可以使用正确的信息进行构建。 当然，在开始开发新版本时必须记住运行此 make 目标。
另一种选择是使用 dist 目标的钩子来替换 sed/awk。但这会使项目的 git 存储库处于没有正确版本号与关联文件关联的状态。
我更喜欢第一个解决方案，因为它还在 git 历史记录中记录了正确的版本号。
当进行 sed/awk 替换时，您更喜欢在“文件内”进行替换，还是像 autoconf/automake 工具那样使用文件内模板进行替换。 我看到这两种方法都有优点和缺点。
您如何处理关联文件的版本控制。 您是否在开发阶段开始时更改它们，您是否在发货之前更改它们，您是否进行文件内替换或您更喜欢使用模板？
谢谢。
I would be interested to in knowing how you out there handle the bumping the version number for new releases issue.
How do you handle the version number in associated files like man pages, etc.
The software is build with the gnu tool chain so autoconf, automake, etc are available and used for the version number of the application. So that information can be reused.
git is used as a vcs.
One possibility would be introduce an extra, new target in Makefile.am that does a sed/awk to replace version number and dates in all associated files. That target could be called once at the beginning (right after branching) of the development of a new release.
Then the project could build with the correct information when people would do a git clone of the project or when a release tarball is done. Of course one has to remember to run this make target when starting development of a new release.
Another option would be to do the sed/awk replacement with a hook for the dist target.But this would put the git repository of the project in a state were no correct version number is associated with the associated files.
I prefer doing the first solution as it also records the correct version number inside the git history.
When doing a sed/awk replacement do you prefer doing it "in-file" or with a template in-file liek the autoconf/automake tools do. I see both advantages and disadvantages in both methods.
How do you handle versioning of associated files. Do you change them at the beginning of the development phase, do you change them when just before shipping, do you do infile replacement or do you prefer using a template?
THX.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
现在常见的解决方案是使用 m4_esyscmd 参数调用 AC_INIT 以从 git 生成版本。 例如，autoconf 的configure.ac 包含以下行：
AC_INIT([GNU Autoconf], m4_esyscmd([build-aux/git-version-gen .tarball-version]), [[email protected]])其中build-aux/git-version-gen 是一个简单的脚本，它调用“gitdescribe”来生成版本号。 （请参阅 gnulib）
这种方法有缺点，但它可能很有效。
A common solution nowadays is to invoke AC_INIT with an m4_esyscmd argument to generate the VERSION from git. For example, autoconf's configure.ac contains the lines:
AC_INIT([GNU Autoconf], m4_esyscmd([build-aux/git-version-gen .tarball-version]), [[email protected]])where build-aux/git-version-gen is a simple script that calls 'git describe' to generate the version number. (see gnulib)
There are drawbacks to this approach, but it can be effective.
我认为执行此操作的标准方法是使用 Git 的钩子系统和 m4 或 sed/awk 来按照您的建议进行搜索/替换。 您只需要在每个文件的注释中添加一个特殊的标记（可能在标头中）。
这是关于 githooks 的参考，这是解决相同问题的人编写的几页：
这两个都依赖于将版本号存储在源树中某处的文件中。
我还遇到了一个名为 0release 的项目，它声称可以自动创建版本（并设置版本号）。
最后，关于版本号，这在其他几个问题中得到解决：
I think that the standard way to do this is to use Git's hook system and m4 or sed/awk to do the search/replace as you suggest. You just need a special token with in a comment in each file (probably in the header).
Here's the reference on githooks and here's a few pages written by people solving the same problem:
Both of these rely on storing the version number in a file somewhere in your source tree.
I also came across a took called 0release that claims to automate release creation (and setting version numbers).
Finally, regarding release numbers, this is addressed in several other questions:
我们使用经典的major.minor.patch系统，它作为“标签”应用于候选版本，我们有一个脚本将提交标记为版本号，而不是使用git“标签对象”。 所有版本编号都是“手动”完成的。 它工作得相当好，因为
版本号是由“发布到暂存”脚本创建的，该脚本是在开发过程的后期进行的。 我们不费心使用任何 git hook，因为我们真的不需要这样做，如果提交没有离开开发环境，那么除了内部 SHA 代码之外，它不需要 id。
我们尝试强制每个“补丁”版本必须与具有相同主要、次要标签的其他版本二进制兼容。
这样，任何带有标签的东西至少应该构建，但它可能或很可能无法按规范工作。
一种改进是让 QA 部门在“QA 批准”的任何内容上创建一个签名标签对象，但目前我们依赖其他文书工作。
We use the classic major.minor.patch system, which gets applied to release candidates as a 'tag', we have a script which tags a commit as the version number, rather than use a git 'tag object'. All the version numbering is done 'by hand'. It works reasonably well, because
the version number is created by the 'release onto staging' scripts, which is much later on in the development process. We don't bother using any of the git hooks, because we don't really need to, if a commit isn't leaving the development environment then it doesn't need id other than it's internal SHA code.
We try to enforce that every 'patch' release must be binary compatible with other versions with the same major,minor tag.
That way, anything with a tag should at least build, but it's possible or quite likely that it won't work to spec.
A refinement would be to get the QA department to create a signed tag object on anything that is 'QA approved' but for now we rely on other paperwork for that.