在HashiCorp terraform0.10中，Terraform被分成两个逻辑组件：Terraform核心和Terraform提供者。这种变化的一个主要动机是承认提供者开发有不同的范围和开发速度。不同的提供者在不断地变化，当你所选择的平台中的一个主要的新特性在Terraform中被延迟时，总是令人沮丧的，因为需要与其他提供者和核心协调发布。单独提供程序版本的一个更普通的方面是单独的提供程序版本号。以前的Core和所有提供程序为每个版本共享一个版本号。用户可能已经注意到，随着新的独立发布计划，提供商已经开始在0.1.0开始他们自己的版本编号方案，并且从那时起一直在增加。观察到Terraform提供程序在许多方面类似于编程语言中的共享库，我们为提供者采用了一种遵循语义版本控制准则的版本编号方案。总之，这意味着具有版本号的表单主要.次要.修补，以下含义适用：只增加补丁的数量意味着这个版本只包含了bug修复，并且在功能上是等价的。增加较小的数量表明已经添加了新功能，但现有功能仍然广泛兼容。增加主数量表示已经进行了重大的突破性变化，因此在升级过程中需要格外小心或注意。在撰写本文时，terraform providers GitHub组织中的大多数提供者仍然使用0.x.x"初始开发"编号，这（根据语义版本规范）表示上述承诺不一定适用。然而，当每个提供者开发团队准备好在这个方案中工作时，它将由一个编号为1.0.0的发行版来表示，之后在将来的发行版中将采用上述约定。特别是对于提供者来说，迁移到1.0.0通常不会代表任何功能上的重大变化或开发速度上的任何变化。大多数提供程序已经具有非常高的质量，并且有一个稳定的开发过程，所以这个版本的更改仅仅是对现有质量和稳定性的承认。»第三方提供商如果不提到第三方提供者，对提供者版本控制的讨论将是不完整的。我们知道，许多Terraform用户为各种附加服务维护自己的提供者，我们很感激其中许多是作为开源项目维护的。随着HashiCorp发行的提供商套件的增长，很明显，将所有这些供应商保持在我们期望的质量水平上是不可能扩展的。因此，当我们改进开发过程时，我们感谢社区和合作伙伴组织中的合作者。我们希望确保每个提供商都有一套高覆盖率的验收测试，以及一个响应能力强的维护团队，他们可以响应问题和请求。因此，我们对在HashiCorp分发集中采用新的提供者持保留态度。在terraform0.10中，Terraform Core中的自动安装机制只支持HashiCorp的服务器，因此第三方提供者仍然必须下载并手动复制到一组本地搜索目录中的一个。在第一个版本中只支持HashiCorp releases服务是一个务实的折衷方案，通过构建已经存在的分发基础设施，允许这种变化更快地发生。为了使第三方构建的提供商同样容易获得和使用，我们计划了一个更通用的分发解决方案。同时，我们建议第三方提供者维护者开始对他们的版本采用类似的语义版本控制方案，使用terraform-provider-NAME_vX.Y.Z方案将这些版本号嵌入到插件二进制文件名中。以这种方式命名的插件二进制文件将被terraform识别为版本控制，因此将与terraform0.10.0中引入的显式提供程序版本控制机制集成。»地形核心的版本控制语义版本控制主要适用于库，因为它的承诺涉及到通过一个定义良好的API与调用软件的兼容性。因此，terraformcore作为一个应用程序，将不会切换到语义版本控制约定，而是将以与其他HashiCorp产品相同的方式继续下去。Terraform已经被许多组织用来维护关键的基础设施，我们非常重视在改进Terraform的可用性和特性集与保持与现有配置和编排的兼容性之间的权衡。在TerraForm0.x的整个发行版中，我们都在不断地听取反馈和改进Terraform，只有在有保证的情况下才进行突破性的更改，并通过更改日志和升级指南来交流这些更改。最终的1.0版本将代表我们采用更强大的向后兼容性承诺的意图，但这需要首先找到正确的配置语言功能集、可维护的内部架构、更完整的模块系统，以及产品的其他各个方面，以便我们能够长期地与1.0功能集兼容。我们的目标是在继续改进的同时，尽可能地与地形的各种现有用途保持兼容。感谢社区在我们继续迭代产品设计时提供的持续反馈！