Semantic versioning

Q: How deeply does Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu cover semantic versioning?

Explains version fields, change categories, constraint operators, and upgrade boundaries through configuration examples.

As explained in Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu

A semantic version is a version identifier following major, minor, and patch precedence rules.

Semantic versioning labels releases as vMajor.Minor.Patch so users can estimate upgrade risk. Patch releases fix bugs, minor releases add backward-compatible features, and major releases indicate backward-incompatible change. section 8.1.1

Apply the version fields as follows:

Start a stable module at v1.0.0. section 8.1.1
Increment Patch for bug fixes or documentation improvements, such as v1.0.1 and v1.0.2. section 8.1.1
Increment Minor and reset Patch when adding features, such as v1.1.0. section 8.1.1
Increment Major and reset the other fields when backward compatibility breaks, such as v2.0.0. section 8.1.1

Constrain Terraform module upgrades

A module can pin one exact release with version = "1.1.1", allow minor and patch updates below 2.0.0 with version = ">= 1.1.0, < 2.0.0", or exclude a known-bad release with version = ">= 1.1.0, < 2.0.0, != 1.3.2". The pessimistic constraint "~> 1.1.0" permits bug fixes within the 1.1 line, while "~> 1.1" permits minor and patch updates below 2.0.0. section 8.1.1

Table 8.2 Example constraints with their allowed versions (view table figure)

Constraint	Allowed versions
= 1.1.1	Only `v1.1.1` is allowed.
>= 1.1.0, < 2.0.0	The minimum version is `v1.1.0`, and any `Minor` or `Patch` versions are allowed. Upgrading the `Major` version is not allowed.
>= 1.1.0, < 2.0.0, != 1.3.2	The same as above, except we’re also forbidding version `v1.3.2` from being used. Excluding specific versions is useful when bugs are introduced to a specific version and then fixed.
~> 1.1.0	The pessimistic constraint operator allows only the rightmost field to be upgraded. In this case, that means `v1.1` and any bug fixes are allowed, but `Minor` and `Major` upgrades are excluded.
~> 1.1	This sets the floor at `v1.1`, but since the rightmost value is the `Minor` field it allows `Minor` and `Patch` upgrades. It is the exact same as `>= 1.1.0,` `<2.0.0` but is more concise.

Compare exact, bounded, exclusion, and pessimistic constraints with their allowed versions. section 8.1.1

Table 8.1 Example changelog and semantic versions (view table figure)

Change	Field to increment	Version
First stable release		v1.0.0
Fix error in variable validation	`Patch`	v1.0.1
Improve documentation	`Patch`	v1.0.2
Expose additional resource parameters as variables	`Minor`	v1.1.0
Fix TFLint rule violation	`Patch`	v1.1.1
Refactor input variable names	`Major`	v2.0.0

Map representative module changes to the version field they increment. section 8.1.1

How Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu covers it

Cover of Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu

liveBook manning.com

Read Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu on liveBook Get the book at manning.com

Also explained in

liveBook manning.com

Building Web APIs with ASP.NET CoreSemantic versioning is a version-numbering convention using MAJOR, MINOR, and PATCH components whose increments communicate compatibility and change significance.
liveBook manning.com

Go in Action, Second EditionSemantic versioning is a versioning convention in which changes to major, minor, and patch components communicate compatibility and release significance.
liveBook manning.com

API Design PatternsA semantic version string is a dotted three-number representation whose major, minor, and patch components communicate the nature of software changes.
liveBook manning.com

The Design of Web APIs, Second EditionA semantic version number is a version identifier with major, minor, and patch components whose changes conventionally communicate compatibility impact.
liveBook manning.com

The Art of CodeSemantic versioning is a version-numbering convention in which major, minor, and patch components communicate compatibility and change significance.
liveBook manning.com

GitHub Actions in Action: Continuous integration and delivery for DevOpsSemantic versioning is a versioning scheme that communicates compatibility and change significance through major, minor, and patch version numbers.
liveBook manning.com

Infrastructure as Code, Patterns and Practices: With examples in Python and TerraformSemantic versioning is a version-numbering scheme in which major, minor, and patch components communicate the kinds of changes between releases.

Compare how 8 books explain semantic versioning →

Related concepts

major versionhas part · A major version is the primary component of a version identifier that distinguishes a release line and commonly signals potentially backward-incompatible changes.
FluentBitused by · Fluent Bit is a lightweight, open-source telemetry agent for collecting, processing, enriching, and forwarding logs and other event data.

This explainer was generated by Manning's knowledge graph from the text of Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu. The section links point to the parts of the book it draws on.