### Terraform Version <!--- Run `terraform -v` to show the version, and paste the result between the ``` marks below. If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed. --> ``` Terraform v0.11.14 + provider.aws v2.17.0 + provider.template v2.1.2 ``` ### Terraform Configuration Files ```hcl terraform { required_version = "~> 0.11.0" backend "s3" { role_arn = "arn:aws:iam::xxxxxxx:role/role_terraform" bucket = "pix4d-terraform-xxxxx" key = "state.tfstate" region = "us-east-1" dynamodb_table = "pix4d-terraform-xxxxxx" workspace_key_prefix = "xxxxx" } } ``` ### Crash Output ``` Terraform doesn't allow running any operations against a state that was written by a future Terraform version. The state is reporting it is written by Terraform '0.12.3' A newer version of Terraform is required to make changes to the current workspace. ``` ### Expected Behavior Able to do `terraform init` on a project that is still using 0.11 ### Actual Behavior If some project in the state store are migrated to 0.12, then the state.tfstate file that is at the root of the state store is indicating `"version": 4` and `terraform init` using terraform 0.11 will fail ### Steps to Reproduce 1. configure a global state store (like in S3) 2. create a terraform project in 0.11 using this state store 3. create a terraform project in 0.12 using the same state store (the state.tfstate at the root of the state store should say `"version": 4`) 4. in the first project (0.11) delete your `.terraform` folder to start from scratch 5. in the first project (0.11) run `terraform init` ### Workaround (Seems to work only if you use workspaces. Using `default` does not work as far as I can tell) 1. Run `terraform init`. It fails 2. Run `terraform workspace select xxx`. If you don't have workspaces and use `default`, create a new one (`terraform workspace new xxxx`) 3. Re-run `terraform init`. This time it works and you can move forward. ### Additional Context Due to the workaround, and the fact that this is a transient thing (while all our repo migrate), this is a low priority issue that can be dealt with. If there is a quick fix though.... ;) To try and clarify a bit more our setup: - we have a company-wide centralized state store in S3. All our teams/projects are using the same state/lock store. - That means that each team uses a different `key` which translates to a "folder" in the S3 store. - Some teams have started to migrate to 0.12 but not all. We obviously don't want to synchronize the migrations and we felt it was ok, since each project states contain it's own version. - However, on `terraform init`, terraform seems to try and use some global state when contacting the global state store which makes it fail. - The funny thing is that there is a workaround. Seems that the first `init` fails but not completely: at least workspaces can be listed. Then you can change workspace. And if you do so, then you have access to a specific state file (I guess) and a further `init` will run (I guess because it ignores the global state file). - Maybe it makes a difference also that we **don't use the default workspace**