Is there a use case for pinning `required_version`...
# terraform
j
Is there a use case for pinning
required_version
to prevent newer versions of the TF cli? I know there was that breaking HCL change a while back (from 0.12 to 0.13 I think?), which if you're still on that version of TF, I can see why it'd be important. But are there other instances where a newer version of TF broke existing Terraform code?
k
Some years back there was a breaking change in the format of the statefiles. This affected codebases (like the one I was working on) which used remote statefiles to look up resources to manage dependencies between projects (like one creating subnets that another project uses). That taught me not to use remote statefiles across projects, so may be less relevant now.
I would use
required_version
to stop major version changes being pulled, to give time for review. Generally speaking, I prefer to pull the latest version automatically in a test environment, then let it propagate if tests pass. Assuming I have a decent pipeline and test suite for the infra code in place. And only pin the version in specific cases where a new version is known to break something in my setup.
j
Yeah, I was thinking about setting it to be something like
~> 1.5
so I'd get everything up until 2.0... but then I started thinking if Hashicorp would really release a 2.0 version that broke all the existing Terraform code in the world?
I really prefer to just float on latest and then pin if something does radically break. That way any minor adjustments you have to make you can make quickly and easily as you go, instead of realizing when you need to upgrade for another reason, and then it's a "do we really need to upgrade because it's going to be two weeks of fix up work" conversation