Patch and emergency update

Not every fault can wait for Monday's week release. For those there are two shorter routes: the patch (a fix on an ordinary working day) and the emergency update (an urgent release, at any time). Both raise only the third number of the version — 0.51.0 becomes 0.51.1 — and both carry fixes only: never anything new, and never a database change that cannot be undone.

This page explains when to take which route, what is prepared for you, and how you roll it out. The rollout itself uses the same buttons as a week release: see Rolling out a release.

Which route?

When in doubt, it is a patch. Anything that is not urgent goes into the next week release. Neither route skips the test setup, and in production the test server always goes first.

A patch

You do not build a patch yourself. What happens:

1. The fix is made in the main line of the source code first, with a test that proves it works.
2. That same fix is taken over into the version that runs in production, and a patch version is made of it, for example 0.51.1.
3. The patch runs at least two hours on the test setup, with the checks that belong to this fix.
4. You receive the path of the release dossier. Besides what you know from a week release, it holds a cherry-pick plan: exactly which fix was taken over.

You then roll out as always:

1. Releases → Production source: enter 0.51.1 under Release set, a reason, click Roll out (in Dutch: Uitrollen) and give your second factor.
2. Update the panel itself (see From a terminal).
3. Releases → Rollout plan → Start rollout from plan. The order is the one of a week release; the wait between waves may be shorter.

An emergency update

You do not do an emergency update alone: you do it together with Claude, in one conversation. It starts with four questions, answered before anything is built:

1. What is happening, since when, and which servers or customers are hit?
2. Is it really an emergency (exploited vulnerability, data loss, outage)? If not, it becomes a patch.
3. Can you stop the damage now without a release — a firewall rule, switching a feature off, a server in maintenance mode? Then do that first.
4. The moment the incident started.

The fix is then made and tested, and after at least thirty minutes on the test setup you roll out — with the same steps as a patch.

The releases board has the emergency lane for urgency. It asks for a reason and shortens the waits (the soak and the bake between waves), but it never skips the canary and never ignores a red check. What the emergency lane does is recorded on the release, on the rollout and in the audit log.

You inform your customers through your own company's status page and channels.

Afterwards

Under Open points the release dossier lists what is still owed:

• forward-port — when the fix could not be taken over directly, it was made in the production version itself and has to reach the main line within one working day as well. While that point is open, no new week release is made: it would undo the fix again.
• full-gate — after an emergency update the full check round runs after all.
• post-incident-review — the review of an emergency update, within five working days: what happened, why the checks did not find it, and what changes.

A point is done when its box is ticked, with where it was done.

From a terminal

On the panel server, as root — the same commands as for a week release, with the patch number:

corecp-panel dist publish 0.51.1 --reason "patch: the save button on the DNS page works again"
corecp-panel self-update --to 0.51.1
corecp-panel self-update status

Which points are still open, across all dossiers at once (in the source code):

python3 scripts/lib/release-dossier.py open docs/release-decisions

On a server, after the rollout:

corectl --version

See also

• Rolling out a release — the week release, step by step.
• Managing releases — the releases board and the emergency lane.
• How CoreCP versions work — why a patch raises only the third number.