github.com/muratcelep/terraform@v1.1.0-beta2-not-internal-4/website/docs/language/expressions/version-constraints.html.md (about)

     1  ---
     2  layout: "language"
     3  page_title: "Version Constraints - Configuration Language"
     4  description: "Version constraint strings specify a range of acceptable versions for modules, providers, and Terraform itself. Learn version constraint syntax and behavior."  
     5  ---
     6  
     7  # Version Constraints
     8  
     9  Anywhere that Terraform lets you specify a range of acceptable versions for
    10  something, it expects a specially formatted string known as a version
    11  constraint. Version constraints are used when configuring:
    12  
    13  - [Modules](/docs/language/modules/index.html)
    14  - [Provider requirements](/docs/language/providers/requirements.html)
    15  - [The `required_version` setting](/docs/language/settings/index.html#specifying-a-required-terraform-version) in the `terraform` block.
    16  
    17  ## Version Constraint Syntax
    18  
    19  Terraform's syntax for version constraints is very similar to the syntax used by
    20  other dependency management systems like Bundler and NPM.
    21  
    22  ```hcl
    23  version = ">= 1.2.0, < 2.0.0"
    24  ```
    25  
    26  A version constraint is a [string literal](/docs/language/expressions/strings.html)
    27  containing one or more conditions, which are separated by commas.
    28  
    29  Each condition consists of an operator and a version number.
    30  
    31  Version numbers should be a series of numbers separated by periods (like
    32  `1.2.0`), optionally with a suffix to indicate a beta release.
    33  
    34  The following operators are valid:
    35  
    36  - `=` (or no operator): Allows only one exact version number. Cannot be combined
    37    with other conditions.
    38  
    39  - `!=`: Excludes an exact version number.
    40  
    41  - `>`, `>=`, `<`, `<=`: Comparisons against a specified version, allowing
    42    versions for which the comparison is true. "Greater-than" requests newer
    43    versions, and "less-than" requests older versions.
    44  
    45  - `~>`: Allows only the _rightmost_ version component to increment. For example,
    46    to allow new patch releases within a specific minor release, use the full
    47    version number: `~> 1.0.4` will allow installation of `1.0.5` and `1.0.10`
    48    but not `1.1.0`. This is usually called the pessimistic constraint operator.
    49  
    50  ## Version Constraint Behavior
    51  
    52  A version number that meets every applicable constraint is considered acceptable.
    53  
    54  Terraform consults version constraints to determine whether it has acceptable
    55  versions of itself, any required provider plugins, and any required modules. For
    56  plugins and modules, it will use the newest installed version that meets the
    57  applicable constraints.
    58  
    59  If Terraform doesn't have an acceptable version of a required plugin or module,
    60  it will attempt to download the newest version that meets the applicable
    61  constraints.
    62  
    63  If Terraform isn't able to obtain acceptable versions of external dependencies,
    64  or if it doesn't have an acceptable version of itself, it won't proceed with any
    65  plans, applies, or state manipulation actions.
    66  
    67  Both the root module and any child module can constrain the acceptable versions
    68  of Terraform and any providers they use. Terraform considers these constraints
    69  equal, and will only proceed if all of them can be met.
    70  
    71  A prerelease version is a version number that contains a suffix introduced by
    72  a dash, like `1.2.0-beta`. A prerelease version can be selected only by an
    73  _exact_ version constraint (the `=` operator or no operator). Prerelease
    74  versions do not match inexact operators such as `>=`, `~>`, etc.
    75  
    76  ## Best Practices
    77  
    78  ### Module Versions
    79  
    80  - When depending on third-party modules, require specific versions to ensure
    81    that updates only happen when convenient to you.
    82  
    83  - For modules maintained within your organization, specifying version ranges
    84    may be appropriate if semantic versioning is used consistently or if there is
    85    a well-defined release process that avoids unwanted updates.
    86  
    87  ### Terraform Core and Provider Versions
    88  
    89  - Reusable modules should constrain only their minimum allowed versions of
    90    Terraform and providers, such as `>= 0.12.0`. This helps avoid known
    91    incompatibilities, while allowing the user of the module flexibility to
    92    upgrade to newer versions of Terraform without altering the module.
    93  
    94  - Root modules should use a `~>` constraint to set both a lower and upper bound
    95    on versions for each provider they depend on.