48 lines
3.7 KiB
Markdown
48 lines
3.7 KiB
Markdown
|
|
||
|
|
# 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](https://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.
|