Guidance for configuring Provider and Terraform Versions

Terraform
1

I am looking for some guidance on how we should be handling:

  1. Provider Version
    1.1 We have parent and child module structure. Can i get some guidance on how to handle provider attribute deprecations and where should we handle the provider version. And also how would large team base affect this versioning. For example how would the provider version affect the state file if a person upgrades to latest and another person brings it back to older version.
    1.2 Any documentation on how the internals work would be helpful

  2. Terraform Version:
    2.1 Any guidance on how terraform version affects the state file will be helpful. A scenario where in we ran with the latest version and some other person want to revert back to older version

2

Hi @Divya1388,

For provider versions the typical process is that you declare in each of your modules which provider versions they are known to be compatible with, using version constraints like this:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = ">= 3.0.0"
    }
  }
}

The above example is declaring that this module was written to work with 3.0.0 or later of the AWS provider. It doesn’t set an upper limit because we cannot predict the future to know if a future provider version will remain compatible. If you do later learn that a subsequent provider release is incompatible with your module then you can make a new patch release of the module which also constrains the upper limit.

When you run terraform init for the first time Terraform will generate a file called .terraform.lock.hcl which remembers all of the exact provider versions Terraform selected. You should add that file to your version control so that everyone on your team can agree on which versions to use. If you later want to upgrade a provider you can run terraform init -upgrade and include the updated .terraform.lock.hcl file in a pull request so that you can discuss the upgrade with your coworkers in the same way as any other code change.

The situation for Terraform CLI itself is different because Terraform doesn’t install its own executable. Therefore if you want to achieve a similar approach for the main Terraform executable you will need some external “version manager” software that your team all agrees to use. A current popular choice for that is asdf because it’s a single tool that can manage many different pieces of software, but this is third-party software so I encourage you to research this for yourself to decide which of these version managers will be most comfortable for your team.

3

Hey @apparentlymart thanks for being kind and explaining this.
Are there any resources you recommend that demo or explain the internals with examples