There may be a reason you want to remove a previously promoted release from a channel. When you do so, the downstream impacts of this release removal can depend on which installer method your customer is leveraging, as well as whether the release has already been fetched by your customer ahead of you choosing to remove it.
First let’s touch on the two methods that allow you to remove a release from a channel in Vendor Portal, and what they are used for:
- Demote a Release - When you demote a release, that release is no longer available for download by customers, but it will not be withdrawn from customer environments where it was already downloaded (see below section for more details based on your installer method). You would choose to demote a release when you no longer want any downstream customers to be able to fetch it when they check for new versions of your software. See docs for how to demote a release in Vendor Portal.
- Archive a Release - When you archive a release, that release will be removed from your list of releases in Vendor Portal, but archiving a previously promoted release will NOT remove the release from the channel’s history page or prevent it from being fetched by your customers when they look for new versions. Archiving a release is most useful when you want to reduce the number of releases that you are viewing on the screen, but all of those prior releases are still valid. See docs for how to archive a release in Vendor Portal. If you have archived a release in error and need to reverse the action, please open a support ticket.
Assuming you’ve chosen to Demote a Release, let’s touch on how that impacts your end customer experience, which depends on the installer method your end-customer is leveraging with your software.
Each installation option handles release demotion a bit differently:
Direct Helm CLI install, instructions via Enterprise Portal
If the demoted release has not yet been downloaded into the end customer environment, when the end customer goes to view the available releases on their Enterprise Portal, the demoted release version will no longer be viewable to the customer from the point of the demotion event.
Embedded Cluster
The Embedded Cluster installer fetches available upstream releases but does not download them. Therefore if an end customer has not yet chosen to deploy the impacted version, that demoted release version will disappear from the available updates option list the next time an upstream version check occurs (either scheduled or user-initiated) post the demotion event.
Existing Cluster KOTS installer and kURL Embedded Kubernetes installer
Updated behavior - Available with KOTS 1.128.0 or later
While newly available releases are still downloaded by the Admin Console after checking for updates in an online installation, in later versions of KOTS the Admin Console will no longer persist the release metadata permanently. Now when a version check is executed (manually or automatically) KOTS will refetch the release metadata for any newer versions that have not yet been deployed.
If you change information about a release, such as removing or marking a release as ‘required’, and/or changing the release name or release notes information, KOTS will refresh to show this updated information in the user’s Admin Console Version History UI.
If you choose to demote one or more upcoming releases that the user has not yet deployed, then KOTS will refresh to hide those demoted releases in the Admin Console Version History UI.
Original behavior - KOTS versions earlier than 1.126.0
Note: The functionality noted above was released in two seperate KOTS releases, hence the gap in versions. 1.126.0 introduced the ability to refetch release metadata and 1.128.0 introduced the ability to hide demoted releases from the UI.
In these two installer products the KOTS Admin Console downloads metadata about newly available releases after an upstream version check and then displays these as available updates to the end customer.
Prior to KOTS version 1.126.0, if an end customer had NOT YET CHECKED UPSTREAM for new versions at the time of a release demotion event, that demoted version would not display. However, if an end customer HAD ALREADY CHECKED UPSTREAM and pulled down that release, even if not deployed yet, before that release was demoted, it would remain as an available release. This is because the release had already been downloaded and could not be withdrawn from that customer’s environment.
Given the two above mentioned installers download the release when available on an upstream version check and persist the release metadata going forward, marking a release as required, and then changing that parameter to not required, or vice versa, also depends on what the release state was when the customer fetched it. If a release was previously marked as required at the time the end customer fetched it from upstream, KOTS will continue to show that release as required even if it that requirement has since been removed in Vendor Portal. For releases that were fetched after the “required” tag was removed, it would be fetched as a non-required release version.
See docs for more info on making a release required and preventing it being skipped on upgrade.