Versions, releases and upgrades

Every NTC module has its own version and its own release cadence. You decide when each module in your Landing Zone moves forward. This page explains what a version number tells you, how to pin it and how to upgrade.

What a version number means

Module versions follow semantic versioning (MAJOR.MINOR.PATCH). Releases are generated from the commit history, so the sections of a release note map directly to the kind of change:

Change	Section in the release notes	Version bump	What to expect
Fix	Bug Fixes	Patch	No change to inputs or outputs
New capability	Features	Minor	New optional inputs, outputs or resources
Incompatible change	BREAKING CHANGES	Major	Changed inputs, moved resources or a new provider requirement

A major version is the only kind of release that asks for more than a version bump. The breaking change is described in the release notes, and larger ones come with an upgrade guide.

Pin every module

Always reference a module with an exact version. An unpinned module changes underneath you on the next init.

Git source

module "ntc_organizations" {
  source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-organizations?ref=X.Y.Z"

  # module inputs
}

Spacelift registry

module "ntc_organizations" {
  source  = "spacelift.io/nuvibit/ntc-organizations/aws"
  version = "X.Y.Z"

  # module inputs
}

Replace X.Y.Z with a released version. The current version of each module is shown at the top of its documentation page and in the module map. The Quickstart describes how a pipeline authenticates to the NTC repositories.

Follow releases

• Release notes list every release of every module, newest first, with a filter per module. Major versions are marked.
• Module pages show the latest release in their title block and link to the filtered release notes.
• /api/releases.json and /api/modules.json carry the same data for scripts, for example to open a pull request when a module you use has a new release. See machine-readable docs.

Upgrade a module

Patch and minor versions

1. Read the release notes between your version and the target version.
2. Change the pinned version in the module call.
3. Run a plan and review it. A patch or minor release should not replace existing resources. If the plan shows replacements you did not expect, stop and check the release notes again.
4. Apply through your pipeline, lower environments first where you have them.

Major versions

1. Read the breaking changes in the release notes and the matching upgrade guide if one exists.
2. Create a backup of the Terraform state before you start.
3. Upgrade one module at a time. Modules are released independently, so a Landing Zone can run different major versions side by side during a migration.
4. Follow the guide for input changes and state moves, then plan and review before you apply.
5. If a plan or apply fails, the troubleshooting page covers the common causes.

Moving from v1 to v2

The v2 generation of the modules adds support for the AWS provider v6 and for the AWS European Sovereign Cloud. Each module has its own guide under Upgrade NTC to v2.

Getting help

Upgrade questions are covered by NTC support. Include the module name, your current version, the target version and the relevant part of the plan output.