Tracks (Versioning)

InfraWeave simplifies the process of publishing, managing, and promoting versions of modules across various environments. This approach is designed to support development, testing, and production workflows seamlessly, as well as accommodate custom environments like feature branches.

Tip

InfraWeave uses semantic versioning when publishing your modules.

Key Concepts

Tracks: A track is a fixed publishing option that communicates the readiness and stability level of your module version. When publishing a module, you must specify one of the 5 predefined tracks. Each track serves as a clear signal to consumers about the maturity and intended use case of that version.

Tracks are isolated from each other, making it easy to maintain separate release pipelines and test different versions without interference.

Available tracks are:

• stable - Production-ready releases (e.g. 1.2.7 or 2.0.1, …)
• rc - Release candidates ready for final validation (e.g. 1.2.7-rc.2, …)
• beta - Feature-complete versions for broader testing (e.g. 1.2.7-beta or 2.0.1-beta.4, …)
• alpha - Early versions with potential breaking changes (e.g. 1.2.7-alpha or 2.0.1-alpha.4, …)
• dev - Development versions for active work and experimentation (e.g. 1.2.7-dev+feature.x.branch or 2.0.1-dev+feature.x.branch.4, …)

Publishing a Version: Modules are versioned entities. You can publish a new version of a module to a specific track using the CLI.

A version is specified in the module.yaml manifest. When publishing you again have to specify the desired track, which has to match, to avoid accidental publishes to e.g. stable.

Automatic tracking: It is possible to follow a track, meaning an application team can specify a track + major instead of a version. This means it is not necessary to look up the latest version. Could be useful for small teams that do not use renovate. TODO

Note

You can decide your own strategy. Not all tracks have to be used, fewer is better, depending on if you are a solo developer or a big organization the needs will differ.

Workflow

Publishing: Use the CLI to publish a new version of a module to a designated environment. For instance, when adding a new feature a descriptive branch name can be provided after -dev following a +-sign to indicate metadata, and a version number.

modules/s3bucket.yaml

apiVersion: infraweave.io/v1
kind: Module
metadata:
  name: s3bucket
spec:
  moduleName: S3Bucket
  version: 0.1.4-dev+add.versioning.configuration.option.1
  reference: https://github.com/my-org/my-s3-module
  description: |
    Description about S3 Bucket here...

This can then be published to the dev-track (current folder)

Publish module to dev environment

infraweave publish dev .

If you are using the provided GitHub actions this is automatically done for you.

Releasing

When merging this branch to a release branch, start with specifying the desired track

modules/s3bucket.yaml

apiVersion: infraweave.io/v1
kind: Module
metadata:
  name: s3bucket
spec:
  moduleName: S3Bucket

  version: 0.1.5-beta.1
  reference: https://github.com/my-org/my-s3-module
  description: |
    Description about S3 Bucket here...

Then in order to publish to the beta-track (or replace with another track):

Publish module to beta environment

infraweave publish beta .