Which versions we offer

A hosting platform runs on other people's software: PHP, MariaDB, Node, LiteSpeed. Each of them has several series alive at once, and every series has an expiry date. This page explains what CoreCP offers, for how long, and what happens when a vendor publishes something new.

The short version: you get a notification, never a surprise. Nothing is built automatically and nothing is installed automatically. A new release inside a series we already offer arrives as work ("build and promote this"); a whole new series arrives as a decision you take.

Offered, security only, or no more fixes

Two things are not the same here, and the difference matters.

What the vendor still does with a series: ordinary fixes, security fixes only, or nothing. That is not ours to decide — it is on a calendar php.net and mariadb.org publish themselves.

What we offer: whether a server can install the series at all. We offer PHP series php.net has finished with, because otherwise a website arriving from another panel cannot be served on day one, and a migration is not a rewrite. What we never do is let that read as a recommendation.

On a server's Components tab each series carries a label:

Only the last one is amber. A customer deliberately kept on PHP 8.2 has made a choice, and a warning colour for a choice is an alarm nobody can act on.

From the command line:

corectl versions --available

What happens when a vendor publishes

The build server looks at php.net, mariadb.org, nodejs.org and LiteSpeed once a day. It is the only machine in the whole platform allowed to: ordinary servers talk to our own infrastructure and never to a vendor.

When it sees a new release inside a series we offer, you get a notification saying "A new release is available". Nothing has been installed; the package still has to be built and promoted through the channels, and that is an administrator's action.

When it sees a series we do not offer at all — PHP 9.0, a new MariaDB LTS — you get "A new major version — a decision is needed". That is not a build job but a product decision: packages to build, a support window to promise, and a way for customers to move.

Both land in your notification centre and stay there until you do something about them. They do not repeat every day.

Advice you can put away

A server's advisor has a "Runtime support" row that reports which series no longer get fixes. If you are running one deliberately — a shop that only moves in the fourth quarter — you can put that row away per series, with a reason:

corectl advisor snooze --subject php:8.2 --days 30 --reason "shop migrates in Q4"
corectl advisor snoozes
corectl advisor snooze --subject php:8.2 --clear

Three things worth knowing:

• It is per series. If another series passes its end date next month, the row is simply back — you did not put that one away.
• It expires. Thirty days by default, ninety at most. There is no "forever": a decision made in March says nothing about September.
• It is written down, so it survives a restart of the server.

What you cannot put away is a series nobody ships security fixes for. The refusal looks like this:

$ corectl advisor snooze --subject php:5.6 --days 30
PHP 5.6 reached its end of life and receives no security fixes — that is not a
setting, it is what the machine is running.

That is not strictness for its own sake. A series somebody else still patches is a choice you made, and a choice may be acknowledged. A series nobody patches is not a choice but a property of the machine, and a panel that lets a fact be hidden is a panel nobody reads any more.

And when Ubuntu ships a new LTS

Every mirror this platform has is pinned to one Ubuntu release, and the PHP builds are compiled against its libraries. A new Ubuntu major is therefore the largest decision the platform has, and it is taken as a project rather than as an upgrade: a server is replaced, not upgraded, and accounts move with the same service move a series change already uses.

The policy is written out in full in docs/versions-policy.md. Nothing is scheduled today.

See also

• Reading the server advisor — where the "Runtime support" row comes from
• Managing releases — channels, waves and rolling back
• A server's PHP policy — what a customer may change themselves