We've removed the main documentation pages for the backends that are
removed in Terraform v1.3, but we'll leave a small callout note so that
the backend names are still reachable through our search index once the
v1.3 docs are the active version.
The primary goal here is to help folks who have inherited configurations
using older versions of Terraform to learn about features they see in those
configurations, so the main thing here is the link to the older release
docs which include those. However, this is also a good opportunity to link
to the upgrade guide content which describes some possible migration
paths away from these removed backends.
Co-authored-by: Matthew Garrell <69917312+mgarrell777@users.noreply.github.com>
Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>
Co-authored-by: Kevin Wang <kwangsan@gmail.com>
Co-authored-by: Judith Malnick <judith@hashicorp.com>
Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
Co-authored-by: HashiBot <62622282+hashibot-web@users.noreply.github.com>
Applying object type defaults to null values can convert null to an
object with partial attributes. This means that even a specified default
value of null will not remain null after variable evaluation.
In turn, the result can then be invalid, if not all attributes in an
object type have defaults specified.
This commit skips the type default application step during config load
and variable evaluation if the default or given value is null of any
type. We still perform type conversion.
Before our website allowed selecting from older versions of Terraform to
see older documentation we needed to preserve all of the historical
upgrade guides in the latest release branch so that they'd stay available
on the website.
However, our new strategy is for each release to have its own separate
set of documentation selectable using a global version selector. We should
therefore now have only the upgrade guide for the each minor release
on its release branch, with the upgrade guides for earlier releases
instead maintained on their own branches.
However, our v1.1 branch is, as a matter of pragmatism, serving as the home
for the "v1.1 and earlier" documentation, and so there will continue to
be multiple upgrade guides on that branch. For that reason, we're
preserving the URL scheme "upgrade-guides" (plural) even though the URL
now points to only a single version upgrade guide because that causes
readers to land in the correct place if they are on a modern version's
upgrade guide page and they use the version selector to choose the
"v1.1 and earlier" option.
