Long Term Support (LTS) version stream

Jenkins X uses version streams as a quality gate when promoting plugins, charts, cli packages, container images etc. This results in a release of Jenkins X.

The default version stream for Jenkins X 3.x is The Jenkins X own infrastructure runs a number of end to end BDD tests for different base install options which covers the core of Jenkins X. Provided these tests pass on from a Pull Request it will be merged and users can upgrade their CLI and Cluster bringing in the versions that make that release.

As Jenkins X uses Continuous Delivery all the way through the stack it means there can be a lot of releases, even many on a daily basis. While we are advocates of Continuous Delivery it can be hard for users to consume the number of releases so often. For teams that are in need of more mature features when they are released it can also bring some risk upgrading from the latest daily release of an open source project.

The Long Term Support (LTS) version stream ( is designed to help with these two scenarios. It is a replica of the latest default version stream described above but will release on a slower cadence. This means users can switch their installations to track the LTS version stream and bring in changes when it suits them. They will see a collection of changes which will have improved documentation and maturity given the feedback from users tracking the latest version stream. Jenkins X own infrastructure uses the latest version stream and automatically upgrades on every release, this is another way we can build confidence in the quality of an LTS release.


To switch your installation clone your cluster git repository

jx gitops versionstream --lts

This will modify and commit a change to your local ./versionStream/Kptfile, it will now point at the LTS version stream.

Next we need to make sure your local jx CLI is aligned with the version in the LTS version stream.

From within the same directory as above run:

jx upgrade cli

Next we will get the LTS version stream and align the helmfile.yaml with the correct versions.

jx gitops upgrade

Now review changes, commit and push to your cluster remote git repository.


To switch back to the latest version stream repeat the steps above with the --latest flag instead. e.g.

jx gitops versionstream --latest
jx upgrade cli
jx gitops upgrade


The monthly cadence of the LTS version stream may still be too frequent if you desire. For this you can fork the LTS version stream, point your installation at the fork and manage syncing your fork with the LTS at whatever cadence suits you best.

To use a custom fork repeat the steps above with the --custom flag and git details instead. e.g.

jx gitops versionstream --custom --url --ref master --directory versionStream
jx upgrade cli
jx gitops upgrade

If it helps this is where we automatically create a pull request on the LTS version stream when we release the latest version stream. You can do the same when updating your custom fork.


git clone
cd "jx3-lts-versions"
git checkout -b foo
jx gitops upgrade --commit-message "chore: version stream upgrade $VERSION"
git push origin foo
jx create pullrequest -t "chore: version stream upgrade $VERSION"

Last modified February 23, 2021: fix: try nicer layout for admin (5d88989bd6)