如何在Tarball交付过程中保留软件版本相关元数据？

针对Tarball交付软件时保留版本信息的问题，有几个成熟的实践方案可以直接采用，解决解压后版本信息丢失的问题：

1. 在归档根目录放置纯文本版本文件 #

这是最通用、成本最低的方案，几乎所有类型的软件都适用：

• 在构建Tarball前，在归档的根目录生成一个纯文本文件，比如VERSION、VERSION.txt或者RELEASE_VERSION，内容可以是简单的版本号（如1.2.3），也可以补充更详细的元数据：

  Version: 1.2.3
  BuildDate: 2024-05-20
  GitCommit: a1b2c3d
  

• 用户解压后一眼就能看到这个文件，排查问题时直接查看；支持脚本也能轻松读取文件内容获取版本信息。
• 构建时可以用一行命令自动生成：echo -e "Version: 1.2.3\nBuildDate: $(date +%Y-%m-%d)" > ./dist/VERSION

2. 将版本信息嵌入可执行文件（编译型软件） #

如果你的软件是编译型的（比如C/C++、Go、Rust），可以直接把版本信息编译进可执行文件：

• C/C++：编译时通过宏定义注入：gcc -DVERSION="1.2.3" main.c -o myapp，然后在代码里打印VERSION宏的值，支持./myapp --version或./myapp -v命令输出版本。
• Go：构建时通过链接参数注入：go build -ldflags="-X main.version=1.2.3" -o myapp，然后在main函数里处理--version参数输出版本号。
• 这种方式用户不用找文件，直接通过命令就能快速确认版本，非常友好。

3. 用结构化元数据文件（类似Java MANIFEST.MF） #

如果你想要类似MANIFEST.MF的结构化方案，可以自定义一个元数据文件：

• 沿用Java的路径习惯，在归档内创建META-INF/MANIFEST.MF，格式和Java的一致：

  Manifest-Version: 1.0
  Implementation-Title: MyApp
  Implementation-Version: 1.2.3
  Build-Date: 2024-05-20
  

• 或者用更通用的JSON格式，创建meta/manifest.json：

  {
    "version": "1.2.3",
    "build_date": "2024-05-20",
    "commit_hash": "a1b2c3d",
    "author": "MyTeam"
  }
  

• 结构化的信息方便脚本解析，也能统一存放更多构建相关的元数据，适合需要自动化版本校验的场景。

4. 写入软件配置文件 #

如果你的软件本身有配置文件，可以直接在配置文件中加入版本字段：

• 比如在config/app.conf中添加：app_version = "1.2.3"
• 如果软件启动时会加载配置文件，可以在启动日志或--version命令中读取这个值并显示，让用户在日常使用中就能看到版本信息。

额外建议 #

• 自动化生成：所有版本信息都应该通过构建脚本自动生成，不要手动修改，避免版本不一致的问题。比如从项目的版本源文件（如pyproject.toml、package.json、VERSION文件）读取版本号，同步到所有需要的地方。
• 双重保障：继续保留归档文件名中的版本号（如myapp-1.2.3.tar.gz），和内部的版本信息形成互补——用户解压前可以通过文件名确认，解压后可以通过内部文件/命令确认。

内容的提问来源于stack exchange，提问作者sbm