Intent type versions are a tool to allow working with different intent type YANG models.

Changing certain attributes in an intent type can affect OSS integrations. If you need to change OSS-affecting attributes, you can create a new version of the intent type with the change, leaving earlier versions available to the OSS. Intents can be migrated between versions of the intent type when the OSS integration has been updated to work with the new version. Intents can be migrated from one version to another, avoiding the need to create them again.

If the new definition of the intent is incompatible with the previous version, for example if a new attribute has been added, you can configure migration handlers and rollback handlers as part of the script of the newer version.

Migration and rollback handler functions can also be used to indicate how approved misalignments are handled when intents are migrated.

The Migration table in the General tab of the new version shows the configured migration paths and the functions that support migration and rollback.

• Supported version: the Supported Version column in the Migration table refers to the “from” version in a migration path. When a version is created, for example, version 3, the migration table is populated with rows for versions 1 and 2. However, migration and rollback handler functions are not automatically assigned.

• Migration handler: the migration handler function ensures that your data instance remains in line with the updated YANG model, for example by adding a new attribute that was included in the newer version.

• Rollback handler: the rollback handler function manages migration from a newer version to an older version, for example, removing an attribute that was added by the new version.

See the Network Intents tutorial on the Network Developer Portal for details about scripting migration.

The artifact version shown in the Artifacts view for an intent type artifact reflects the delivery version of the artifact. For example, version 1.0.1 has some minor changes relative to version 1.0.0, version 1.1.0 has major changes, and version 2.0.0 is a new release of the artifact.

For Nokia-created intent types, the format is release_x.y.z where the numbers x.y.z are used for version control. The x number is the Version parameter in NSP. For example, if you install an intent type with the build number 24.11.0-rel_2.5.1, the intent type version will be 2, regardless of whether you have a version 1 in your system.

Artifact version management in the Artifacts views is based on the artifact version, not on intent type versions created in Network Intents. See Version management best practices for information about installing new versions of artifacts when older versions are in use.