Releases and support
Operating it
What is in each release, how long it is supported, and how to reach us.
What "supported" means, which releases have it, and what to do when yours stops. Written down because an auditor asks for it in writing, and because a promise nobody can look up is not one.
What is supported
The current release, and the one before it.
A release is supported from the day it is published until two further releases have been published after it. So with 0.3.0 current, 0.2.0 is supported and 0.1.0 is not.
There is no time limit attached to that, in either direction. A quiet period does not retire a release, and a busy one does not retire it faster than the rule says.
What support covers
Security fixes. Backported to the supported previous release, not only to the current one.
Fixes for faults that lose or corrupt data, or that stop a supported deployment working.
Answering questions about a deployment on a supported release.
What it does not cover
New features. Those land on the current release and are a reason to move, not something backported.
Faults in a release that is no longer supported. The answer is to upgrade, and the upgrade path is the same one you already use.
Changes to the deployment you have made yourself: a rendered manifest edited by hand, an image rebuilt locally, a value the chart does not expose.
Finding out where you stand
Three places, and they agree because they read the same feed:
System health in the portal names the release you are running, the latest one, and the support status published alongside each.
https://nyxus.co.uk/releasescarries the same list, publicly, with no sign-in. That is the page to send an assessor.GET https://registry.nyxus.co.uk/updatesis the feed both read.
A release nobody has published a support status for shows none. Absent means absent, not supported - if you need it in writing for an audit and the page does not say, ask.
When a release stops being supported
Nothing breaks, switches off, or phones home about it. A deployment on an unsupported release keeps running exactly as it did: the images you have already pulled are yours to run for as long as your subscription term lasts.
What stops is the fixing. If a security fault is found in a release that is two behind, the fix goes into the current release and you move to it.
This matters beyond our arrangement. Cyber Essentials asks that software in scope be licensed and supported by its vendor, with unsupported software removed or segregated - an assessor can read the releases page and see the answer. ISO 27001 does not name versions, but your own policy almost certainly says you run supported software, and an auditor holds you to your own policy. Neither is a reason to upgrade on its own. Both are a reason to know where you stand before somebody asks.
Upgrading
nyxusctl upgrade runs on your machine, with your kubeconfig or Docker context, and the portal only approves it. See the Updates panel on System health for the exact commands for your deployment, or Upgrading Nyxus.
Moving between supported releases is a version bump. Anything that needs more than that is called out in the release notes for the release that needs it, and a release that needs it is not published quietly.
Reporting something
Security faults: privately, and not as an issue. See the security guidance for the route.
Everything else: through whoever your subscription names. Include the version from System health, the deployment route, and what the receiver's own metrics say - Troubleshooting says which numbers are worth sending, and why.
The small print this replaces
Nothing. This is a statement of intent, not a service level agreement, and it does not vary the terms in LICENSE. Where the two differ, the licence governs. A contracted response time is a separate conversation and a separate document.