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.
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.
This is a new-shaped representation of check results which follows the
two-tiered structure of static objects and dynamic instances of objects,
thereby allowing consumers to see which checkable objects exist in the
configuration even if a dynamic evaluation error prevented actually
expanding them all to determine their declared instances.
Eventually we'll include this in the state too, but this initially adds it
only to the plan in order to replace the now-deprecated experimental
conditions result that was present but undocumented in Terraform v1.2.
This is a complement to "timestamp" and "timeadd" which allows
establishing the ordering of two different timestamps while taking into
account their timezone offsets, which isn't otherwise possible using the
existing primitives in the Terraform language.
Previously we didn't describe the interaction between default values and
callers explicitly passing "null".
We treat an explicit null as the same as omitting the attribute when
applying defaults, because that then allows callers to use the typical
pattern for conditional assignment, using explicit null as a fallback
to the module's defined default without having to duplicate that default:
example = var.foo ? "hello" : null
We've been holding on to this snapshot of the old docs from the v0.11
branch ever since the v0.12 release as a courtesy to folks who are still
using Terraform v0.11, since until now we didn't have any way to serve
older versions' docs on the website alongside the current aside from
snapshotting it forward in this way.
However, our website framework now supports publishing multiple versions
at the same time and so the final resting place for these v0.11 docs will
be in the "v1.1" branch, whose content is serving as the documentation
for the "v1.1 and earlier" version selection on the website. While it does
still feel a little awkward to have v0.11 be a subsection of the v1.1
docs, this is at least more honest in that v0.11 _is_ earlier than v1.1,
whereas it's confusing and weird for it to appear under the "v1.2.x"
option and the other versions that will appear later.
In order to avoid breaking incoming links to the old docs we will deploy
this in conjunction with some additional redirects managed by the top-level
terraform-website repository, which will send all paths with the prefix
/language/configuration-0-11 to the equivalent path under
/language/v1.1.x/configuration-0-11 . That redirect rule must exist
outside of this repository because it's a bridge _between_ versions of
the website in this repository, rather than a link to other content within
the same version.
