问题标签 [versioning]

我目前正在与其他五个开发人员一起开发一个项目，我们正在使用 subversion 作为我们的修订控制系统。我们已经确定，在我们的软件首次发布之前，我们有 12 个里程碑。我们使用版本号（0.1 到 0.12）和描述性标签标记了里程碑。例如：

• 0.1 - 导航
• 0.2 - 搜索
• 0.3 - 用户管理

但是，每隔几个里程碑就会有一个由之前的里程碑组成的外部版本。因此，我们最终会得到以下内容：

• 0.1 - 导航
• 0.2 - 搜索
• 0.3 - 用户管理
• 0.4 - 阿尔法 1

这些里程碑中的每一个都可以并行开发，但它们也需要并行进行质量检查。我们通过在 subversion 中为每个里程碑创建分支来做到这一点，只需用里程碑的版本号标记。自动化系统独立构建每个里程碑，并使用里程碑编号和构建应用程序的颠覆修订号对应用程序进行版本控制。版本号显示在应用程序的显着位置，因此当 QA 团队查看版本号时，他们可以将其与特定的里程碑联系起来，并知道哪些需要进行 QA，哪些不需要。一旦里程碑通过了 QA，它将被合并到主干中，并且任何正在进行的开发都将使用最新代码进行更新。

但是，有一个假设（正确地），版本号的增加包括所有以前的版本。不幸的是，对于上述方案，这可能不会发生，因为一个里程碑可能在另一个里程碑之前完成。例如，0.3 可能会在 0.1 之前完成。这意味着我们将有一个不包含 0.2 或 0.1 功能的内部 0.3 版本。

这是我的问题。当多个并行版本（内部或其他）可能不按顺序完成时，我如何智能地对软件进行版本控制？

我们的情况如下，但我对这个问题在任何情况下都很好奇。

我们有一个由 4 个项目组成的框架：

• 豆子
• 实用程序
• 框架
• 网络

我们也有需要版本的模块，并且依赖于 bean 和 util 的版本。

最后，我们有一个客户项目，它由特定版本的核心项目和一个或多个模块组成。

是否有标准方法来对这些项目进行版本控制？

对我来说似乎很简单的事情变得非常复杂，因为我们尝试将发布交付给 QA，然后通过维护发布（发布 = 标签和可能的分支）来管理我们正在进行的开发。

我更喜欢以下内容：

1.2.0 - 主要和次要版本 + 发布。

1.2.1 - 下一个版本

1.2.0_01 - 1.2.0 版本（分支）中的错误修复

等等

有任何想法吗？

有比较版本号的标准习语吗？我不能只使用直接的 String compareTo，因为我还不知道最大发布点数是多少。我需要比较版本并满足以下条件：

我正在寻找一些关于命名程序集和对其进行版本控制的良好做法。您多久增加一次主要或次要版本？

在某些情况下，我看到版本直接从 1.0 版升级到 3.0 版。在其他情况下，它似乎停留在 1.0.2.xxxx 版本。

这将用于整个公司的多个项目中使用的共享程序集。期待一些好的输入。

我需要澄清两种情况：

1. 使用 .NET 3.5 编译的可执行文件需要使用使用 .NET 1.1 编译的库，并且该库必须在 1.1 运行时上运行。

2. 使用 .NET 1.1 编译的可执行文件需要使用使用 .NET 3.5 编译的库。

我找不到可靠的消息来源说明无法加载两个版本的 .NET 运行时，并且 Microsoft 的文档在此问题上非常含糊。

如果 A 引用程序集 B 1.1 和 C，而 C 引用 B 1.2，如何避免程序集冲突？

我很好地假设 C 的引用会被封装掉并且不会导致任何问题，但似乎所有的 dll 都被复制到了 bin 中，这就是问题发生的地方。

我了解解决此问题的两种方法是使用 GAC 或程序集绑定？GAC 对我来说似乎不是最好的方法，因为我不喜欢假设 dll 会在那里，我更喜欢在我的解决方案中从 lib 目录中引用 dll。

由于程序集绑定对我来说似乎不健壮，如果程序集的一个版本具有另一个版本没有的功能怎么办，这不会产生问题吗？

在我的情况下，因为我使用的是第 3 方 dll，它使用的是旧版本的 nHibernate，而不是我自己使用的。

如果我更改 WCF，是否必须在所有访问该服务的客户端计算机上运行某种更新？（即运行 svutils.exe 并更新所有 app.config 等？）

我目前正在自动化/改进包装我商店的整个产品的发布流程。目前该产品是以下产品的组合：

• Java 服务器端代码库
• XML 配置和应用程序文件
• 面向管理员的 Shell 和批处理脚本
• 静态提供的 HTML 页面
• 和其他一些东西，但这是大部分

所有或大部分都包含各种版本信息，用于不同的目的。发布打包过程的一部分涉及进行大量查找、grep'ing 和 sed'ing（在脚本中）以更新信息。这种包装产品的胶水似乎是以一种有机的、及时的方式拼凑在一起的，而且维护起来非常糟糕。例如，一些 Java 方法在发布时创建 Date 对象，其参数通过文本替换更新，无需编译器验证......只是，呃。

我试图避免给出实际使用的软件（即 CVS、SVN、ant 等）的示例，因为我想避免“使用 xyz 的功能来做到这一点”并更多地关注一般实践。我想将问题归咎于劣质设计，但如果我不得不重新开始，仍然使用不同的技术，我不确定如何最好地处理这个问题，而不是制定约定。

我的问题是，对于跨不同技术、文件类型、平台和版本控制系统维护和更新版本信息，是否有任何最佳实践或提示和技巧？

我在 Linux 上有一个可执行文件，它加载libfoo.so.1（即 a SONAME）作为其依赖项之一（通过另一个共享库）。它还链接到另一个系统库，而后者又链接到系统版本libfoo.so.2. 结果，两者 libfoo.so.1都在执行期间被加载，并且libfoo.so.2本应从版本 1 的库中调用函数的代码最终会从版本 2 的较新系统库中调用（二进制不兼容）函数，因为某些符号保持不变。结果通常是堆栈粉碎和随后的段错误。

现在，链接到旧版本的库是一个封闭源代码的第三方库，我无法控制libfoo它编译的版本。假设剩下的唯一选择是重建一堆当前链接到的系统库libfoo.so.2以链接到libfoo.so.1.

有没有办法避免用链接到旧的本地副本替换系统库libfoo？我可以加载这两个库并让代码调用正确版本的符号吗？所以我需要一些特殊的符号级版本控制？

我想使用 maven 发布插件发布一个快照项目“foo-1.0-SNAPSHOT”。该项目依赖于尚未发布的第 3 方模块“bar-1.0-SNAPSHOT”。我在项目的 pom.xml 中使用选项“allowTimestampedSnapshots”来允许时间戳快照，但我假设第 3 方模块（栏）没有时间戳，除非我自己构建它，因为 maven 仍然抱怨未解决的 SNAPSHOT 依赖项。

无论依赖的 SNAPSHOT 项目如何，有没有办法发布项目 foo，如果没有，我如何向第 3 方项目添加时间戳？