# Versioning

The *nplus chart versioning* is tied to the *nscale Application Layer* version, as we want to use `helm upgrade --version 9.2.1200` to upgrade to nappl 9.2.1200 for instance. As the Application Layer upgrades the database scheme in minor releases, this is the crutial version number.

As the component charts also need to be deployable solo, so e.g. deploy a *nplus-component-web* chart into an existing instance, also the components use the version of the corresponding nscale component version. 

So we end up having an *instance chart* version that is equal to the *nplus-component-nappl* chart version and a bunch of other components that might have different versions in that bundle, all tied to the component version.

The *nplus code versioning*, meaning the version of the chart code, is written to the `appVersion` field in the `Chart.yaml`, so with a `helm list`, you will get both versions.

The code is versioned with tags. If different code is necessary for specific versions of nscale, this is handled by the chart. So the latest chart code should be able to handle the latest nscale version and all versions below (since 8.0, the first container release). You can always take the code tagged with version and appVersion in the Chart.yaml and mix in completely different nscale versions to deploy a specific release with the current code version. Please see the samples how to do that.

## Version Scheduling

nscale releases monthly versions latest on the first weekday of the month. At the end of the first week, nplus releases the corresponding chart version. Since it is tied to the nscale versioning, also minor and major releases are using 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](https://semver.org)).

Beta Versions get tagged with `-<build>`. In SemVer 2 syntax, these are pre-releases to the next version. In order to get the sorting correctly (so helm correctly fetches the *latest* version), pre-releases must use the version of the next release. Since these Versions are named by Ceyoniq for the nscale software, we do not know the next version for sure (but their naming theme is pretty straight and strict).

However, what nplus does for this case is to increase the patch and use that on as the minimal next version. So after the release of version `9.2.1201` (nappl, thus als nplus), we will get the next development version `9.2.1202-1`. Until the next nscale release, probably being something like `9.2.130x`, when the pre-release then gets released and takes this version.

## helm

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

If you want to test with the latest development beta release, you can install `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 Practise

- 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 in 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 used code can be determined.