Extremely unprofessional backward incompatible release

[bbnathan]

It is my understanding (and experience) that the Terraform developers strive to provide backward compatibility. Releasing this prior to the official 0.12 release is not only premature, but unprofessional at best. It breaks the vast majority of our templates, forcing us to review every stack we have written since we adopted the tool. This release should never have happened.

Terraform Version

All versions prior to 0.12 (which has not been released at this time).

Affected Resource(s)

terraform_template

Terraform Configuration Files

data "template_file" "user_data" {
  template = "${file("${path.module}/user_data.tpl")}"
  vars {
    deployment_environment = "${var.environment}"
    nr_license_key = "${var.nr_license_key}"
  }
}

Expected Behavior

Correctly formatted shell script

Actual Behavior

Incorrectly formatted shell script that prevents instances from launching.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Standard ASG

References

Release 2.0.0 Changelog
https://github.com/terraform-providers/terraform-provider-template/blob/master/CHANGELOG.md

[apparentlymart]

Hi @bbnathan,

Thanks for starting this conversation, and sorry that this release led to errors in your existing configurations where the template version number was not pinned.

The HashiCorp-distributed Terraform providers (of which template is one) all use semantic versioning to communicate about the content of each release. Under semantic versioning, incrementing the major version number is how we communicate that a release contains breaking changes.

In the Provider Versions documentation you can see the syntax for and recommendations about specifying specific provider version constraints in your configuration. The terraform init command prints out the following warning whenever run with an unconstrained provider, to encourage adding a major version constraint for it:

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.template: version = "~> 1.0"

Following this advice will allow you to stay on the 1.x.x line of template provider for as long as you wish, without risk of adopting intentional breaking changes in new releases. We recommend doing that in your root modules for every provider you use, as terraform init itself recommends. The version constraints printed by that command are sufficient to pin to the major version that is current at the time the warning was printed.

While indeed we aim to make breaking changes infrequent, they are occasionally necessary to continue to evolve the product. For providers in particular, we use semantic versioning to communicate about those changes. There are more details about this (including information about the different versioning scheme used for the main Terraform CLI) in the blog post HashiCorp Terraform Provider Versioning, which was originally published as part of the release of Terraform 0.10 but remains generally true today.

Since this issue doesn't represent any specific work we could do to improve the situation, I'm going to close it. Thanks again for starting this conversation, and again sorry that your unpinned configurations were affected by these changes.