如何维护版本中的修订/构建组件？

Question

阅读了大量文章/问答/常见问题解答/书籍后，我开始思考 [MAJOR].[MINOR].[REV] 是最有用的版本控制架构 描述项目版本之间的兼容性（版本控制架构 适用于开发人员，不适用于营销）。

主要更改向后不兼容，需要更改 项目名称、文件路径、GUID 等。

较小的更改是向后兼容的。标记新品介绍 特征。

REV 用于安全/错误修复。向后和向前兼容。

在我的工作中，许多项目都依赖于存储的内部库 在发布服务器 (FTP) 上。它们有不同的版本，例如：

  1.0.0
  1.1.0
  1.1.1

依赖库的路径包括版本组件和硬版本 在构建脚本中编码，用于自动下载到 lib 目录。

问题：通常的做法是包含库的路径 为内部开发构建脚本？

问题：最好是：在库名称中包含版本号或 不是？要包括哪个组件？例如：

  libfoo-1.so
  libfoo-1.2.jar
  libfoo-2.3.14.dll

如果仅包含 [MAJOR]，则可以在源中内联库名称 并且随着版本的更改，您不需要修改任何代码。作为 库有固定名称，您始终可以在以下位置询问库版本 运行时（通过调用适当的函数）。

如果包含 [MAJOR].[MINOR] 组件，则每个细微更改 需要更新所有受影响的项目（调用 LoadLibrary， CLASSPATH 环境变量）。并且您无法在运行时检查版本 在运行时搜索库的标准机制通常是 不允许按带有通配符的名称加载（如“libbar-2.*”）。

我认为不需要包含 [REV] 。你只需要 以某种方式提供此组件用于错误报告。

问题：我计划实现这样的模式：将包发布到 路径，例如：

  /srv/projs/foo/1.2.2

并创建了到

  /srv/projs/foo/1.2

先前路径的符号链接。所以每个依赖的项目都不需要make 获取最新库的任何步骤。有人使用这样的架构吗？

Answer 1

如果您仍然不使用（任何）SCM，那么您就走错了路。
如果您不使用可以与使用的 SCM 集成的构建器 - 您又走错了路径

文件的永久名称（其中没有*任何版本号）是最简单的维护方法源（你必须在构建时修改任何内容）