Versioning

The nplus chart versioning is tied to the nscale Application Layer version. For example, we want to be able to run helm upgrade --version 9.2.1200 to upgrade nappl to 9.2.1200. Since the Application Layer upgrades the database schema in minor releases, this is the critical version number.

Component charts also need to be deployable on their own, for example to deploy a nplus-component-web chart into an existing instance. Therefore, component charts use the version of the corresponding nscale component.

So we end up with an instance chart version that matches the nplus-component-nappl chart version, plus a bundle of other components that can have different versions, each tied to its component version.

The nplus code version, meaning the version of the chart code itself, is written to the appVersion field in Chart.yaml. With helm list, you can see both versions.

The code is versioned with tags. If different code is required for specific nscale versions, the chart handles it. The latest chart code should work with the latest nscale version and all versions below (since 8.0, the first container release). You can always take the code tagged with the version and appVersion in Chart.yaml and mix in different nscale versions to deploy a specific release with the current code version. See the samples for how to do that.

Version Scheduling

nscale releases monthly versions, no later than the first weekday of the month. At the end of the first week, nplus releases the corresponding chart version. Because it is tied to nscale versioning, minor and major releases follow the nscale schedule: April and October for minors, and April of every odd year for majors.

Version Naming

The versioning uses SemVer 2 (see semver.org).

Beta versions are tagged with -<build>. In SemVer 2 syntax, these are pre-releases of the next version. For sorting to work correctly (so Helm pulls the latest version), pre-releases must use the version of the next release. Because these versions are named by Ceyoniq for the nscale software, we do not know the next version for sure (but their naming pattern is consistent and strict).

In this case, nplus increments the patch and uses that as the minimum next version. So after releasing version 9.2.1201 (nappl, and therefore nplus), the next development version is 9.2.1202-1. That remains in place until the next nscale release, likely something like 9.2.130x, when the pre-release is released and takes that version.

Helm

If you just use helm install, you will always get the latest released version available. Be careful, as you might end up with an Application Layer version you do not want. It is better to pin the version you want with something like helm install --version 9.2.1200.

If you want to test with the latest development beta release, you can use helm install --devel, which gives you the latest beta.

You can query available versions with helm search repo nplus --versions --devel.

So...

helm search repo nplus lists the latest released version of every component available
helm search repo nplus --devel lists the latest available version of every component available, including beta versions
helm search repo nplus --versions --devel lists all available versions of every component

Best Practice

Use version pinning.
Use the right channel (--devel for dev, released for QA and prod).

Using the chart source code

The code in the git repository is updated automatically with the build version during development. So the Chart.yaml files get a new version with every push. The appVersion refers to the source code in the original (private) repo so that, in case of a support call, the exact code used can be determined.

3.7 KiB Raw Blame History