Given the breadth of available Terraform plugins, ensuring a consistent experience across them requires a standard guideline for compatibility promises. These guidelines are enforced for plugins released by HashiCorp and are recommended for all community plugins.
Observing that Terraform plugins are in many ways analogous to shared libraries in a programming language, we adopted a version numbering scheme that follows the guidelines of Semantic Versioning. In summary, this means that with a version number of the form MAJOR.MINOR.PATCH, the following meanings apply:
Version numbers above 1.0.0 signify stronger compatibility guarantees, based on the rules above. Each increasing level can also contain changes of the lower level (e.g. MINOR can contain PATCH changes).
Increasing the MAJOR number is intended to signify potentially breaking changes.
Within Terraform provider development, some examples include:
Removed on an attribute or removing the attribute definition altogether)TypeSet to TypeList and TypeList to TypeSet)Default: "one" to Default: "two")MINOR increments are intended to signify the availability of new functionality or deprecations of existing functionality without breaking changes to the previous version.
Within Terraform provider development, some examples include:
TypeInt to TypeFloat)Increasing the PATCH number is intended to signify mainly bug fixes and to be functionally equivalent with the previous version.
Within Terraform provider development, some examples include:
Optional when an attribute can not be configured in the remote API)Required to Optional, fixing validation)For better operator experience, we provide a standardized format so development information is available across all providers consistently. The changelog should live in a top level file in the project, named CHANGELOG or CHANGELOG.md. We generally recommend that the changelog is updated outside of pull requests unless a clear process is setup for handling merge conflicts.
The upcoming release version number is always at the top of the file and is marked specifically as (Unreleased), with other previously released versions below.
NOTE: For HashiCorp released providers, the release process will replace the "Unreleased" header with the current date. This line must be present with the target release version to successfully release that version.
## X.Y.Z (Unreleased)
...
## A.B.C (Month Day, Year)
...
Information in the changelog should broken down as follows:
These should be displayed as left aligned text with new lines above and below:
Entry FormatEach entry under a category should use the following format:
* subsystem: Descriptive message [GH-1234]
For provider development typically the "subsystem" is the resource or data source affected e.g. resource/load_balancer, or provider if the change affects whole provider (e.g. authentication logic). Each bullet also references the corresponding pull request number that contained the code changes, in the format of [GH-####] (for HashiCorp released plugins, this will be automatically updated on release).
To order entries, these basic rules should be followed:
provider)resource/load_balancer then resource/subnet)## 1.0.0 (Unreleased)
BREAKING CHANGES:
* Resource `network_port` has been removed [GH-1]
FEATURES:
* **New Resource:** `cluster` [GH-43]
IMPROVEMENTS:
* resource/load_balancer: Add `ATTRIBUTE` argument (support X new functionality) [GH-12]
* resource/subnet: Now better [GH-22, GH-32]
## 0.2.0 (Month Day, Year)
FEATURES:
...
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4