Recommend to maintain latest two MAJOR/minor versions

[ozbillwang]

Hi there,

Terraform Version

v0.9.x
v0.8.x

Affected Resource(s)

New added resources/data store can't be used by v0.8.x

As we know, the version of v0.8.x and v0.9.x are incompatible, especially of the commands terraform init and terraform remote.

Will HashiCorp release the GA version v1.0.0? Does Hashicorp have any plans to maintain two Major/Minor versions? (refer http://semver.org/)

For example, in above versions, if there are new resources and data store added, can we also add them in old version v0.8.x (which is the latest of v0.8) and upgrade to v0.8.9 as well?

My company's CI/CD pipeline environment locked terraform versions, that we can only upgrade terraform to latest v0.8.x, but can't upgrade to v0.9.x. Because it will break other team's build job.

[ozbillwang]

Ok, we have v0.10.x now, looks like HashiCorp doesn't have the plan to go to GA.

[apparentlymart]

Hi @ozbillwang!

At this time there is no specific schedule for a 1.0 release. I'm sorry if something we said created the impression that there was.

Terraform remains under active development so at this time we are only actively supporting the latest release. There will eventually be a 1.0 release, at which time our approach will likely change, but with the core architecture still evolving a lot in each release it is not really feasible to maintain older versions at the moment.

However, the forthcoming 0.10 release separates the provider and core release cycles, so once upgraded to 0.10 it will be possible to upgrade the providers independently and use separate versions in each configuration. We hope this will help address some of the current frustrations like you describe here where upgrading the whole application at once is difficult and risky.

With that said, we are aware of orgs that have CD pipelines set up in such a way that each job may have Terraform upgraded separately. Since Terraform is a single binary, it can work to install different versions either in different directories or with different names. For example, the "tools" idea in Jenkins can allow automatically setting the PATH environment variable on a per-job basis to choose a Terraform version.

[Mic92]

What versions would you recommend to keep around in downstream linux distributions? In our case nixpkgs: NixOS/nixpkgs#45117 (comment)

[apparentlymart]

Hi @Mic92!

That's probably worthy of its own top-level issue since I expect it's a pretty complex subject, but my first reaction is: since the Terraform team is not currently able to offer significant support for anything but the latest version, and this project continues to move fast, I think I would recommend against packaging Terraform in Linux distributions since most Terraform users will wish to stay up-to-date with new releases.

The position on this is likely to change when we reach 1.0, since our intent is for that release to represent a compatibility promise such that it would be reasonable for users to stay on that Terraform Core release (any bugs notwithstanding) for the foreseeable future while still having access to new provider features. While at the moment all available provider releases are compatible with all versions of Terraform, we expect there to be at least one protocol compatibility break before we reach 1.0 to deal with some new requirements for the forthcoming 0.12 release.

I expect that the policies for some Linux distributions could find it problematic that Terraform is designed to download and install provider plugins directly from a HashiCorp server. In this sense it is somewhat similar to many language runtimes, where developers might install the runtime and package manager from a distribution repository but then install their own application's dependencies from the language-native repository. I don't know if this concern applies to NixOS, but I just wanted to point that out in case it isn't clear.

If you'd like to discuss this further, I'd suggest opening a new issue for it since it's often hard for us to keep track of ongoing discussions in closed issues.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.