Terraform's 0.14 release candidate tests more than configuration compatibility

An infrastructure CLI can reject an unchanged workflow even when its configuration language still accepts the same files. Network certificate handling, stored dependencies and state interpretation all participate in compatibility. Terraform's first 0.14 release candidate exposes changes in those areas before the stable release.

HashiCorp publishes 0.14.0-rc1 on November 11. The candidate's tagged changelog still labels the target release unreleased. Its contents describe the candidate available for evaluation, without establishing that a final 0.14 release has already shipped.

I find release candidates most useful when they make specific compatibility questions visible. For Terraform, those questions extend beyond whether a familiar plan looks the same. A tool that coordinates providers and remote services also inherits the behavior of its own network client and persisted metadata.

Dependency selection becomes recorded information

The candidate introduces a lock file generated by terraform init. The changelog describes checking that file into version control so later initialization can make the same version selections. Selecting the newest permitted provider on every installation is no longer the only available behavior.

The documented way to request that newer selection is terraform init -upgrade. A version constraint still defines what is acceptable, while the lock file records a particular choice. Those declarations answer different questions and need not change at the same time.

The candidate also checks that locked dependencies satisfy provider requirements for every command. That can expose a configuration change made since initialization. A stale selection is therefore a concrete compatibility condition, with an explanation tied to the requirements and lock file.

This is useful when a workflow previously relied on fresh installations selecting a newly published provider automatically. The candidate makes that selection an operation with a recorded result. A successful prior initialization does not establish that later requirement changes already have matching selections.

Sensitivity crosses expression boundaries

Input variables can now declare sensitivity, and Terraform propagates that property through expressions derived from them. Outputs referencing sensitive values must also declare sensitivity, or planning returns an error. The candidate therefore makes information flow relevant to output declarations.

The distinction between input and output annotations matters in reusable modules. A module can receive sensitive information and derive another value from it. The caller should not need to assume that transforming the value automatically removes its sensitive character.

The candidate also includes the provider_sensitive_attrs experiment. That experiment extends propagation to sensitivity information declared by providers for resource attributes. The changelog keeps it separate from the ordinary input-variable feature because broadening propagation can cause substantially more values to require sensitive output declarations.

This is a concrete reason to distinguish settled candidate behavior from optional experiments. A module exercising sensitive input variables is testing one set of rules. Enabling provider-attribute propagation tests a broader set that the release explicitly labels experimental.

HTTPS compatibility includes certificate names

The upgrade notes change hostname verification for outbound HTTPS from Terraform CLI. A certificate without appropriate subject alternative names no longer gains hostname validity merely from its common-name field. The certificate must list the hostname as a DNS name in its subject alternative names.

That affects the connection before Terraform can consume a remote service's useful response. Rewriting a resource block does not repair a certificate lacking the required name. The compatibility question concerns the endpoint and the trust information used to reach it.

The candidate also enforces TLS downgrade-protection checks. Its notes call out possible connection errors where proxies or other intermediaries behave in ways resembling a downgrade attack. This is a documented transport condition, without implying that every proxy will fail.

On macOS, Terraform uses the system Security framework to access trust roots. The official binaries also require macOS 10.12 or later. Those are executable-environment changes with a different scope from provider argument validation.

State compatibility follows the file format

Another candidate change allows reading and writing compatible state files even when a future Terraform version produced them. The limit is a state-format change. The changelog's promise is conditional on format compatibility, rather than an unconditional guarantee about every future executable.

That distinction matters for the meaning of version metadata. A newer writer version does not necessarily mean the file representation itself has changed. Conversely, willingness to accept a newer writer cannot make an incompatible representation understandable.

The candidate removes terraform 0.13upgrade and its associated upgrade mechanisms. Its notes direct users to complete the preceding upgrade before moving to 0.14. Compatibility with a state format does not imply retention of every earlier migration command.

I consider these concrete boundaries the useful material in this candidate. Dependency selections become recorded, sensitivity can require additional output declarations, and transport checks can reveal endpoint problems before any infrastructure operation. Each behavior has an identifiable input or environment condition.

The release candidate lets those conditions be evaluated against a specific build. Its prerelease status remains part of that evaluation. The November announcement provides a candidate and its documented behavior, while the stable release is still pending.