【问题标题】:What about terraform versioning scheme?那么 terraform 版本控制方案呢?
【发布时间】:2020-02-22 11:04:20
【问题描述】:

我已经使用 terraform 有一段时间了,我总是有一个疑问,terraform-core 使用的是哪个版本控制方案

它是 语义版本控制 AKA semver 吗?因为如果是,为什么要在次要版本中进行升级,例如将项目从 0.11.X 升级到 0.12.Y 时,会用 0.12.x 写入 terraform 的状态,并且不允许将其降级回 0.11.x?

与此相关的另一件事:为什么他们选择以 0.X.X 而不是 1.X.X 开头的版本号?有什么意思吗?

【问题讨论】:

  • 在 semver 和 1.0 之前的版本中,允许在次要版本中进行重大更改。因此,使用 Terraform 核心,您可以预期 0.11 和 0.12 之间的重大变化。
  • semver.org 解释说,1.0 之前的 API 不能被认为是稳定的,并且在任何版本更改中都允许进行重大更改。在实践中,重大更改往往会增加次要版本,而不是补丁版本,即使它们没有添加任何新功能。

标签: terraform versioning


【解决方案1】:

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

以下是 Hashicorp 员工在GitHub issue 上关于他们的版本控制方法的回答:

在 HashiCorp,我们非常重视 v1.0 的想法,一旦 Terraform 到达那里,它将代表强大的兼容性承诺,因为我们相信配置语言、内部架构、CLI 和其他产品功能适合长期的。

Terraform 的当前状态更加微妙。我们仍然认为向后兼容性非常重要,因为我们知道今天有很多生产基础设施依赖于 Terraform。因此,我们必须做出妥协,这样我们才能在我们可以做出 v1.0 承诺的事情上不断取得进展。虽然我们将这些中断降到最低,但它们并非总是可以避免,因此我们会尝试在更新日志中以及在适用的情况下在升级指南中对它们进行非常明确的说明。

考虑到这一点,目前我们建议在升级之前始终参考更新日志,因为这是我们记录升级期间适用的任何特殊注意事项的主要方式。我们尝试保留重大的重大更改,以增加版本号中的第二个(传统上是“次要”)位置,这代表我们在努力最终实现 v1.0 时的“主要”开发里程碑。

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

很抱歉,我们的版本编号做法在这里造成了混乱;根据这些反馈,我们将在宣布每个版本时尝试更清楚地了解每个版本的重要性和风险,并将努力针对我上面写的内容编写一些更明确的文档。

参考:https://github.com/hashicorp/terraform/issues/15839#issuecomment-323106524

【讨论】:

    【解决方案2】:

    迟到总比不到好:https://www.hashicorp.com/blog/announcing-hashicorp-terraform-1-0-general-availability

    从这里开始,您可以期待常规语义版本控制支持。

    【讨论】:

    • 好一个@Mike!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-01-29
    • 2018-10-09
    • 1970-01-01
    • 1970-01-01
    • 2016-01-21
    相关资源
    最近更新 更多