LLVM 的新版本方案
从历史上看，LLVM 的主要版本总是将版本号增加“0.1”，从而产生 3.8、3.9 和 4.0（预计在 2017 年 3 月发布）等主要版本。然而，在我们的下一个版本中，我们将改变这一点。 LLVM 版本号现在将随着每次主要版本发布而增加“1.0”，这意味着在 LLVM 4.0 之后第一个主要版本将是 LLVM 5.0（预计在 2017 年 9 月发布）。我们相信这种方法将为版本控制提供一种更简单、更标准的方法。
LLVM 的版本号（许多子项目，如 Clang、LLD 等，也共享此版本号）由三部分组成：major.minor.patch。社区每六个月发布一个新版本，其中包含 bug 修复的“补丁”版本（也称为“点”或“稳定”版本）。
到目前为止，每六个月的发布都会导致版本号的minor 部分加 1。每五年，当minor 达到 9 时，就会发布一个更重要的版本，其中包含一些重大更改：2.0 引入了 bitcode 格式，3.0 引入了类型系统重写。
在关于 3.9 之后的版本命名讨论期间，有人指出，由于我们的版本发布是基于时间而不是基于功能，因此主要版本和次要版本之间的区别显得随意。此外，每个版本也都是 API 突破性的，因此根据语义版本控制的原则，我们应该增加主版本号。
我们决定，未来，每个六个月的发布周期都会是一个主版本发布。补丁版本将像以前一样增加patch 部分（产生 5.0.1 这样的版本），minor 部分将保持为零，因为不会进行次要版本发布。
Bitcode 兼容性
在 LLVM 4.0.0 之前，开发者策略规定，LLVM 生成的 bitcode 可被下一个版本（直到下一个主版本发布）读取。开发者策略的新版本规定，LLVM 目前将加载 3.0 或更高版本生成的任何 bitcode。当开发者决定放弃对某些旧的 bitcode 功能的支持时，策略将更新。API 兼容性
没有任何改变。与以前一样，补丁版本与主版本在 API 和 ABI 上兼容，C API 为了稳定性而进行“最佳努力”，除此之外，LLVM 的 API 在发布之间会发生变化。次要版本怎么办？
由于minor 版本始终为零，为什么不将其删除，只使用major.patch 作为版本号呢？从版本字符串中间删除次要组件会导致歧义：x.y 是major.minor 还是major.patch 将取决于x 的值。
版本号也通过各种 API 公开，例如 LLVM 的 llvm-config.h 和 Clang 的 __clang_minor__ 预处理器宏。从这些 API 中删除minor 组件将破坏许多现有代码。
展望未来，由于minor 数字将为零，并且补丁版本是兼容的，我预计我们通常会简单地通过它们的major 数字来引用版本，并将版本字符串的其余部分视为细节（就像 Chromium 55 实际上可能是 55.0.2883.76 一样）。未来版本的 LLVM 和 Clang 通常可以简单地称为“LLVM 4”或“Clang 5”。