The request usually arrives on a Tuesday, by way of a changelog. The framework's next major version wants PHP 8.5, or the analytics team has found a feature that only PostgreSQL 18 offers, and the server they have in mind runs Debian 13, which ships PHP 8.4 and PostgreSQL 17 and will go on shipping those two majors until it retires. The admin knows the usual answers before the sentence is finished: a repository maintained by somebody else, with its own signing key, or a container that brings half a distribution along with the one program anybody asked for.
Both answers do the job, and both are workarounds for a decision taken long before the request, by people who never met the application: that the operating system's release decides which version of everything on it you may run.
That decision sits with the wrong party. A release ought to promise the operating system. The applications on top of it keep their own calendars, set by their own upstreams, and an admin should be able to follow those calendars without leaving the system's own package manager. FreeBSD has worked that way from the start, and on a FreeBSD server the Tuesday request ends with a different package name.
One release, one calendar
Debian 13 was released on 9 August 2025, and with it a set of versions that will not change in substance for as long as it is supported. The rules for what may still enter a stable release are short. Debian's Developer's Reference asks that the bug "must be fixed in unstable already" and that it "should be of severity 'important' or higher". Security fixes arrive; new major versions wait for the next release, which in Debian's rhythm means roughly two years.
This morning I looked up, in the package indexes of Debian 12 and Debian 13 for amd64, eight bog-standard stacks that a good many servers exist to run:
Debian 12 Debian 13
PostgreSQL 15 17
PHP 8.2 8.4
Python 3.11 3.13
Node.js 18 20
MariaDB 10.11 11.8
OpenJDK 17 21, 25
Ruby 3.1 3.3
Go 1.19 1.24Every row changes from one release to the next, and none of them changes in between. Inside Debian's own archive, the PostgreSQL major is a property of the operating system: to move from 15 to 17, you upgrade Debian. Backports soften this for a handful of packages, and for these eight stacks Debian 13's backports carry three newer releases of Go and nothing else.
Debian has good reasons for all of this. One release is one tested combination of tens of thousands of packages, with a security team behind exactly those versions for the life of the release and a long-term team after that. Nothing moves between point releases unless something is broken, and for the floor of a server, the C library, the shell, the network tools and the SSH daemon, that is precisely what one wants.
The trouble starts above the floor, where applications keep calendars of their own. The PostgreSQL project "supports a major version for 5 years after its initial release", so five majors are supported at any given moment, and which of them an application needs is decided by the application. A distribution that ships one of the five will sooner or later ship the wrong one for somebody, and that somebody's admin gets the Tuesday request.
Two calendars
FreeBSD separates the two from the start. The Handbook puts it plainly: "FreeBSD is bundled with a rich collection of system tools as part of the base system. In addition, FreeBSD provides two complementary technologies for installing third-party software", the Ports Collection and the binary packages built from it. The base system is one tree with one version number, 15.1-RELEASE plus its patch level, and it moves with the release. The Ports Collection, which its manual page dates to FreeBSD 1.0, keeps a calendar of its own: a branch is cut at the start of every January, April, July and October, and for the rest of the quarter it receives fixes only, security updates included even when they bring a new version.
Applications in the ports tree are versioned by name. postgresql17-server and postgresql18-server are different packages, and so are php84 and php85. I counted the same eight stacks in this quarter's package catalogue for FreeBSD 15. That makes thirty-two released versions against Debian 13's nine, or twelve with backports.
FreeBSD 14 and FreeBSD 15 each get a package catalogue of their own (38,336 packages in the one, 38,333 in the other, for anyone keeping score), and for these eight stacks the two contain the same thirty-five packages, with the same names and the same versions, down to the patch level. FreeBSD 14 carries a single extra, an older Go. A server still on FreeBSD 14 and one already on 15.1 install the same PostgreSQL 18.6 from the same quarterly branch, and the operating system release does not enter into it.
The two calendars also decide how soon a new version can be had. PostgreSQL 18 was released on 25 September 2025, and its port had been in the tree since 8 May of that year, as a beta, for anyone who wanted to test an application against it. Red Hat added it to RHEL 10 with the 10.2 release, in May 2026.
Availability, mind, is not the same as installing everything at once. PHP and PostgreSQL install one version per system, because PHP's own port declares every other PHP a conflict and because two PostgreSQL servers would want the same file names, whereas Python carries its version in its file names and installs side by side. Two PHPs on one host therefore live in two jails, each with its own package set on the same base system, which is rather less fiddly than it sounds.
The adjustment this asks of an admin who comes from Debian is a small one, and most of it happens in the head: the release looks after the system, and each application's version is chosen for that application.
The strongest objection
Two answers come back from the Linux side.
The first is Red Hat's. RHEL 10 ships Application Streams, several versions of the same stack, each with a published end date: PostgreSQL 16 is supported for the full life of the release and PostgreSQL 18, which arrived with 10.2, until November 2030; PHP and Python follow the same pattern. That is the two-calendar model with a contract attached. It arrives with the point releases, however, and Red Hat decides which versions make the journey: two per stack in most cases, and PostgreSQL 18 eight months after its release.
The second is what everybody else does. The PostgreSQL project runs its own apt repository and aims to build "for all PostgreSQL versions supported", much as others do for PHP and Node.js, and official container images exist for each of these stacks in each of their versions. They work, and many teams run on little else. Each of them, though, rebuilds the missing second calendar on top of an operating system that has only one: another signing key and another archive outside the distribution's security team for every stack, which is a fair bit of rigmarole for a version number, or, with a container, a second userland for every application, to be patched on its own. My book calls a container image "a snapshot of a snapshot", and the phrase fits this case rather well.
FreeBSD offers the same choice from the project's own repository, signed with a key the system trusts already, and the same versions reach every supported major release. One vulnerability database, VuXML, covers the whole ports tree, so pkg audit -F checks every installed package against the same list, whichever stack it belongs to. A second apt repository cannot say as much for itself. And whoever cannot wait for the next quarter switches the package source from quarterly to latest, one line in a repository file, and gets the ports tree as it stands that week.
The limit
The quarterly branch is a best-effort promise. Fixes are merged "on a best effort basis", and a version leaves the tree when its upstream support ends (PostgreSQL 13 is no longer in this quarter's catalogue). Nobody signs an end date. Where a contract is a requirement, it is bought separately, as it is on Linux; where it is not, the upstream's own calendar decides, and the ports tree follows it.
Two versions of PHP or PostgreSQL on one system need two jails. Debian's PostgreSQL packaging can run several majors side by side on one host, provided a repository supplies them; on FreeBSD the same arrangement is two jails on one base system, which is the separation a production setup would want in any case.
The base system keeps one calendar, deliberately. The components imported into it, OpenSSH and OpenSSL among them, move with the FreeBSD release, which is the floor doing its job.
The comparison is with the stable server distributions. Fedora and Arch move faster, and the argument above concerns Debian and RHEL as most servers run them, with Ubuntu's LTS releases in Debian's camp.
On the FreeBSD server, Tuesday's request is answered with a different package name, and the operating system is not consulted. A release ought to freeze the floor and leave the furniture to whoever lives there.
Debian 12 and 13 differ in every one of eight common application stacks, and nothing changes in between. FreeBSD 14 and 15 install the same 35 application versions from the same quarterly packages, 32 of them released, against Debian 13's nine. A release ought to freeze the floor and leave the furniture to whoever lives there.