我目前正在自动化/改进包装我商店的整个产品的发布流程。目前该产品是以下产品的组合：
所有或大部分都包含各种版本信息，用于不同的目的。发布打包过程的一部分涉及进行大量查找、grep'ing 和 sed'ing（在脚本中）以更新信息。这种包装产品的胶水似乎是以一种有机的、及时的方式拼凑在一起的，而且维护起来非常糟糕。例如，一些 Java 方法在发布时创建 Date 对象，其参数通过文本替换更新，无需编译器验证......只是，呃。
我试图避免给出实际使用的软件（即 CVS、SVN、ant 等）的示例，因为我想避免“使用 xyz 的功能来做到这一点”并更多地关注一般实践。我想将问题归咎于劣质设计，但如果我不得不重新开始，仍然使用不同的技术，我不确定如何最好地处理这个问题，而不是制定约定。
我的问题是，对于跨不同技术、文件类型、平台和版本控制系统维护和更新版本信息，是否有任何最佳实践或提示和技巧？
创建一个包含版本号的属性文件，并让所有不同的组件都引用该属性文件
确实，要完成 Craig Angus 的回答，这里的经验法则应该是在您的正常交付文件中不包含任何元信息，而是将这些元数据（版本号、发布日期等）报告到一个特殊文件中-- 包含在版本中 --。
当您使用一个 VCS（版本控制系统）工具从开发到认证再到预生产时，这会有所帮助。
这意味着无论何时加载工作空间（用于开发、测试或准备发布到生产环境），它都是版本控制工具，它为您提供所有详细信息。
当您准备交付（一组打包文件）时，您应该向 VCS 工具询问您想要保留的每个元信息，并将它们写入包含在所述文件集中的特殊文件中。
该交付应打包在外部目录中（任何工作区之外），并且：
如果它是非官方版本，则复制到共享目录（或 maven 存储库）（但只是一个快速打包，用于帮助隔壁等待您交付的团队）。这样你一天可以送 10 或 20 次，没关系：它们很容易丢弃。
导入到 VCS 中以用作正式交付，并且为了易于部署，因为您只需要向版本控制工具询问正确交付的正确版本，然后您就可以开始部署它。
注意：我刚刚描述了一个主要用于许多相互依赖的项目的发布管理过程。对于一个小的单个项目，您可以跳过 VCS 工具中的导入并将您的交付存储在其他地方。
除了 Craig Angus 之外，还包括所用工具的版本。