Operating System Releases & Update Tracking
Point releases, LTS cut-offs, security patch levels and distribution end-of-life dates — the calendar that decides when your machines stop being safe to run.
Operating systems are the only software on a device that everything else depends on, which makes their release cadence the single most useful thing to track. A desktop OS ships a feature update once or twice a year but a security patch level every month, and the two are governed by completely different rules. Missing a feature update costs you functionality; missing a patch level costs you exposure.
The confusing part is that no two vendors describe their cadence the same way. Android reports a 'security patch level' as a date string, Windows uses a cumulative KB number, Apple uses a build identifier alongside the marketing version, and Linux distributions split the difference between rolling and point releases. We normalise all of these into a single event stream so a version bump on Debian and a QPR on Android read the same way in a feed.
What this category tracks
- Point and feature releases
- Major and minor version bumps for desktop, mobile and server operating systems, including beta and release-candidate channels where the vendor publishes them.
- Security patch levels
- Monthly and out-of-band patch bundles, mapped to the advisory identifiers they close.
- Distribution lifecycle dates
- LTS windows, end-of-standard-support and end-of-life cut-offs, which are deadlines rather than releases.
- Kernel and base image updates
- Upstream kernel releases and the container base images that inherit from them.
What matters most here
End-of-life dates are the events most people miss, because nothing arrives to announce them. An OS that has passed its support window keeps booting and keeps looking normal while quietly no longer receiving fixes. Tracking lifecycle deadlines as first-class events — not just releases — is the difference between planning a migration and discovering one is overdue.
Where this data comes from
- Vendor release-notes pages and official security bulletins
- Distribution announcement mailing lists and release RSS feeds
- Public kernel and base-image release trackers
- Published lifecycle and support-window calendars
Every indexed entry links to its primary source. See our editorial and sourcing policy for what we verify and what we do not.
Common questions
What is the difference between a version number and a patch level?
The version number describes the feature set — what the OS can do. The patch level describes how current the security fixes are. Two devices can report the same version and still be months apart on patches, which is why we surface both fields separately rather than collapsing them into one label.
Why do some entries show a date instead of a version?
Some vendors, Android most notably, identify a security bundle only by the date it covers. Where no semantic version exists we keep the vendor's own identifier rather than inventing one, so the value in the feed matches the value you will see on the device.
Tracked releases in Operating Systems
The live release list for this category loads below.
Guides covering this area
End-of-Life Dates: The Deadlines Nobody Announces
Support windows, LTS branches and deprecation schedules are the only release events where nothing arrives to tell you they happened. How to find them and why they need to be stored, not read.
SecurityTracking Security Advisories Without Drowning in Them
Tens of thousands of vulnerabilities are published every year and almost none of them are yours. A practical method for filtering advisories down to the ones that require action.
VersioningHow Version Numbers Actually Work
Semantic versioning, calendar versioning, build identifiers and security patch levels — four incompatible schemes, what each one promises, and where those promises break down.