Terraform 地形版本控制方案呢？

我使用terraform已经有一段时间了，我的脑海中总有一个疑问，terraform核心使用哪个版本控制方案

它是语义版本控制吗？因为如果是这样，为什么要在次要版本中进行升级，比如将项目从0.11.X升级到0.12.Y时，用0.12.X写入地形状态，而不允许将其降级回0.11.X

---

另一件相关的事情：为什么他们选择在0.X.X而不是1.X.X中开始他们的版本号？这有什么意义吗？

他们确实使用语义版本控制，但他们的解释与大多数人略有不同

以下是Hashicorp员工关于其版本控制方法的回答：

在HashiCorp，我们非常重视v1.0的概念，一旦Terraform实现，它将代表一个强大的兼容性承诺，因为我们相信配置语言、内部体系结构、CLI和其他产品功能适合长期使用

目前的地形状态更微妙一些。我们仍然认为向后兼容性非常重要，因为我们知道有很多生产基础设施取决于TrRAFLM今天。因此，我们必须做出妥协，以便我们能够继续朝着我们可以做出v1.0承诺的目标前进。虽然我们将这些中断保持在最低限度，但它们并非总是可以避免的，因此我们尝试在变更日志和升级指南（如果适用）中非常明确地说明它们

考虑到这一点，我们建议在升级之前始终参考变更日志，因为这是我们在升级过程中记录任何特殊注意事项的主要方法。我们试图保留重大突破性更改，以增加版本号中第二个传统次要位置，这在目前代表着我们的主要开发里程碑，因为我们正在努力实现最终的v1.0

由于Terraform是一个应用程序而不是一个库，我们不打算完全遵循语义版本控制惯例，但由于它们确实代表了常见的版本控制习惯用法，我们可能会在精神上遵循它们，因为我们当然希望尽可能清楚。正如@kshep所指出的，v0版本在semver约定中是特殊的，但semver中v1.0的含义与我们打算如何解释它大体一致

很抱歉，我们的版本编号做法造成了混乱；基于此反馈，我们将在发布每个版本时尝试更清楚地了解其重要性和风险，并将致力于就我上面所写的内容编写一些更明确的文档

---

Ref:

它们确实使用语义版本控制，但它们的解释与大多数版本略有不同

以下是Hashicorp员工关于其版本控制方法的回答：

在HashiCorp，我们非常重视v1.0的概念，一旦Terraform实现，它将代表一个强大的兼容性承诺，因为我们相信配置语言、内部体系结构、CLI和其他产品功能适合长期使用

目前的地形状态更微妙一些。我们仍然认为向后兼容性非常重要，因为我们知道有很多生产基础设施取决于TrRAFLM今天。因此，我们必须做出妥协，以便我们能够继续朝着我们可以做出v1.0承诺的目标前进。虽然我们将这些中断保持在最低限度，但它们并非总是可以避免的，因此我们尝试在变更日志和升级指南（如果适用）中非常明确地说明它们

考虑到这一点，我们建议在升级之前始终参考变更日志，因为这是我们在升级过程中记录任何特殊注意事项的主要方法。我们试图保留重大突破性更改，以增加版本号中第二个传统次要位置，这在目前代表着我们的主要开发里程碑，因为我们正在努力实现最终的v1.0

由于Terraform是一个应用程序而不是一个库，我们不打算完全遵循语义版本控制惯例，但由于它们确实代表了常见的版本控制习惯用法，我们可能会在精神上遵循它们，因为我们当然希望尽可能清楚。正如@kshep所指出的，v0版本在semver约定中是特殊的，但semver中v1.0的含义与我们打算如何解释它大体一致

很抱歉，我们的版本编号做法造成了混乱；基于此反馈，我们将在发布每个版本时尝试更清楚地了解其重要性和风险，并将致力于就我上面所写的内容编写一些更明确的文档

参考：迟做总比不做好：

从现在起，您可以期待定期的语义版本控制支持。

迟做总比不做好：

---

从现在起，您可以期待常规的语义版本控制支持。

在semver和pre 1.0中，允许在次要版本中进行破坏性更改。因此，使用Terraform core，您可以期望在0.11和0.12之间发生突破性变化。解释1.0之前的API不能被认为是稳定的，任何版本更改都允许进行破坏性更改。实际上，即使没有添加任何新功能，中断更改也会增加次要版本，而不是修补程序版本。在semver和1.0之前的版本中，允许在次要版本中进行中断更改。因此，使用Terraform core，您可以期望在0.11和0.12之间发生突破性变化。解释1.0之前的API不能被认为是稳定的，任何版本更改都允许进行破坏性更改。实际上，即使没有添加任何新功能，破坏性的更改也会增加次要版本，而不是补丁版本。好的@Mike！好的，迈克！