Manage Version Lifecycle
Configure version lifecycle rules in the Harness IaCM Module Registry to classify module versions as supported, update required, or deprecated, and control enforcement in pipelines.
This topic walks you through configuring version lifecycle rules on a module in the Harness IaCM Module Registry, choosing how each tier is enforced, and adding manual overrides for exceptions.
Version lifecycle management classifies each module version into one of three tiers: supported, update required, or deprecated. You define a sliding window rule that assigns those tiers automatically based on how recent each version is. When a pipeline uses a module, Harness checks the module version against the rule and either lets it proceed, logs a warning, or fails the run, depending on the enforcement behaviour you set for that tier.
Optionally, you can pin a specific version to any tier with a manual override, for example to archive a broken version or to continue using a deprecated version for testing.
What you will learn
By the end of this topic, you will be able to:
Identify the three version lifecycle tiers.
Configure a sliding window rule that classifies versions automatically.
Set the enforcement behaviour for each tier.
Add manual overrides for exceptions.
Understand how enforcement runs during a pipeline and what users see.
Before you begin
Registered module: A module already registered in the IaCM Module Registry. Go to Register a Module to add one.
Published versions: The module has more than one published version. Lifecycle tiers apply only when multiple versions exist.
Edit permission: You need the Edit permission on the IaCM module registry resource to configure lifecycle rules or overrides. Anyone with View permission can see the lifecycle status, but only Edit lets you change the rule. Go to RBAC in Harness to configure roles, and go to the Permissions reference to review the IaCM permissions.
Three lifecycle tiers
Every version falls into one of the following three tiers. Supported versions are always allowed. For the other two tiers, you set an Enforcement behaviour that controls what happens when a pipeline uses a version in that tier.
Supported
The most recent versions. You can reference them without any warning.
Not enforced
Update Required
Versions just outside the supported range. You are warned but not blocked by default.
Configurable. Default: Warning
Deprecated
All older versions. These should not be used, for example because of security gaps or known issues.
Configurable. Default: Fail
A version's badge (Supported, Update Required, or Deprecated) appears in the version dropdown and the module detail header, so you can see its status without opening the Lifecycle Management tab.
How are tiers assigned to a version?
You define two numbers, and a sliding window assigns tiers from the newest version down:
most recent versions (N): How many of the most recent versions are supported.
next versions after supported (M): How many versions after the supported ones are in the update required tier.
Everything older falls into the deprecated tier. Versions are ordered by semantic version, newest first, not by publish date. A backport patch published later than a higher version does not jump ahead of the tier.
For example, with most recent versions set to 3 and next versions after supported set to 2, on a module whose latest version is v2.3.0:
Supported:
v2.3.0,v2.2.0,v2.1.0Update required:
v2.0.0,v1.9.0Deprecated: everything older
When you publish v2.4.0, the window slides automatically. v2.4.0 becomes supported, the oldest supported version drops into update required, and so on.
NEW VERSIONS SHIFT THE WINDOW
Publishing a version can move existing versions down a tier. A pipeline that passed yesterday can start to warn or fail today, with no change to the consumer's code, because a newer version was published. Tell consumer teams about the rule before you set the deprecated tier's Enforcement behaviour to Fail, and start with a generous supported count.
Configure a lifecycle rule
Complete the following steps to configure the sliding window and enforcement behaviour on the module's Lifecycle Management tab:
In Harness, navigate to the module in the IaCM Module Registry and select the Lifecycle Management tab.
Click to view full size The Lifecycle Management tab with the sliding window configuration fields.
Under Supported versions, set most recent versions to the number of newest versions to keep supported.
Under Update required window, set next versions after supported to the number of versions to flag, then set the Enforcement behaviour (default Warning).
Under Deprecated, set the Enforcement behaviour (default Fail).
Click Save Changes. The rule takes effect immediately.
Add manual overrides for exceptions
A manual override pins a specific version to any tier, regardless of where the sliding window would place it. An override always wins over the window. Complete the following steps to add a manual override:
On the Lifecycle Management tab, under Manual override, select Add override.
Click to view full size The Manual override panel where you select the version, target tier, and reason for the exception.
In Version, select the version to override.
In Status, select the tier to pin the version to: Supported, Update required, or Deprecated.
In Reason, enter why you are overriding the version, so other admins understand the exception.
Click Save Changes.
To remove an override, click the × icon next to it. The version then follows the sliding window again.
Common uses:
Archive a bad version: A version that would otherwise be supported has a known critical bug, so you pin it to deprecated. Any pipeline that resolves that version then fails.
Extend support for an exception: A team needs more time to migrate off a deprecated version, so you pin that version to supported or update required for a period.
How tier enforcement works during a pipeline run
Enforcement happens inside the Harness IaCM pipeline step, not at the registry level. The check runs after terraform init resolves the module versions and before plan proceeds. The Enforcement behaviour you set for a tier maps to one of the following outcomes:
No enforcement: The version proceeds with no message. This is always the case for supported versions.
Warning: The pipeline step succeeds but logs an upgrade notice that names the module, the current version, and the recommended version.
Fail: The pipeline step errors out before plan, with a message naming the module, the version, its status, and the minimum supported version.
Best practices
Resolved version is checked: If your Terraform code uses a version constraint such as
~> 2.0, the version thatterraform initresolves is the one evaluated.Direct references only: Enforcement applies to modules referenced directly in your workspace. Transitive dependencies (a module that depends on another module) are not evaluated.
Plan is the gate: Enforcement runs at plan time. A plan that passes is not re-evaluated at apply.
Harness pipelines are the boundary: Running Terraform locally or outside Harness bypasses lifecycle enforcement by design.
Troubleshooting
Next steps
Go to Module Registry Overview to understand module structure, settings, and governance.
Go to Register a Module to register a module in Harness IaCM.
Go to Module Artifacts to learn how artifact storage and the onboarding pipeline work.
Go to Test a Module to validate module changes before consumers use them.
Go to Govern Module Usage to understand OPA-based governance for module usage.
Go to Provider Registry to understand the provider counterpart to the module registry.
Last updated
Was this helpful?