Dropping platform support: announcing the end of old OSes, browsers, and runtimes

Most breaking changes alter what your product does. A platform drop alters where it runs: the code may be byte-for-byte identical, but after some date it no longer supports macOS 12, or Internet Explorer, or Node 16, or 32-bit Windows, or TLS 1.1. For the people affected it’s the harshest kind of breaking change, because the fix isn’t “update your code” — it’s “replace your operating system,” and often they can’t.

That asymmetry is what makes the announcement matter. You’re not asking users to absorb a rename; you’re telling some fraction of them that the road ends here unless they change something expensive, slow, or entirely outside their control. This guide covers what counts as a platform drop, the support policy that makes each one boring instead of a fight, how to write the announcement itself, and — the part most teams skip — what happens to the installs you leave behind.

What counts as dropping a platform

The category is wider than “old Windows.” All of these are platform drops, and every one deserves the same announcement discipline:

• OS minimums — raising the minimum macOS, Windows, iOS, or Android version; ending updates for a version you previously shipped to.
• Browsers — dropping IE yesterday, old Safari today; moving your web app to a feature baseline that older engines don’t have.
• Runtimes — a library raising its minimum Node, Python, Java, or Ruby; per the semver guide, dropping a runtime is breaking even when your code didn’t change, because “runs where it ran yesterday” is part of the promise.
• Architectures — ending 32-bit builds, dropping Intel Macs, requiring instruction sets older CPUs lack.
• Protocols and crypto — turning off TLS 1.0/1.1 (RFC 8996 formally deprecated them), retiring old cipher suites or API auth schemes; the client that breaks is often an appliance nobody can patch.
• Hardware revisions — ending updates for rev-A devices while rev-B continues; the firmware guide treats these like API removals, announced early and precisely.
• Cascading floors — your minimum rises because a dependency’s did. It’s still your announcement to make; “upstream made us” is context, not a substitute.

Publish a support policy before you need one

The difference between a routine drop and an angry one is usually whether the rule existed before the drop did. Like a deprecation policy, a support policy is written in calm weather and does its work every time after. Three shapes cover almost everyone:

• Rolling window — “the current and previous two macOS releases,” “Node versions in active or maintenance LTS,” “browser versions in Baseline widely available.” Each drop becomes arithmetic, not news: when the window moves, support moves with it, on a schedule anyone can compute years ahead.
• Fixed list with review dates — an explicit support matrix, revisited on a stated cadence. More work to maintain, clearer for enterprise readers who need to plan against specific rows.
• Usage threshold — “we consider dropping a platform when it falls below 1% of active use, with at least 90 days’ notice.” Honest only if you publish the notice period too; a bare threshold reads as “we’ll drop you whenever the graph says so.”

Whichever shape you pick, put the policy on a permanent page, link it from every drop announcement, and — the hard part — follow it even when the old platform is annoying to keep alive. A policy you override the first time it binds you is marketing, not policy.

The people you’re dropping usually can’t move

Write the announcement remembering who’s on the old platform. Almost nobody runs macOS 12 or Android 9 out of enthusiasm. It’s a corporate image they don’t control, a 2015 laptop that works fine, a phone that stopped receiving OS updates years ago, a regulated environment where upgrades need change approval, a lab instrument driving hardware whose vendor is gone. “Just upgrade” is advice for the users who least need it.

Be equally careful with the usage statistic that justifies the drop. Measure before announcing, say what you measured, and remember your telemetry undercounts exactly the environments most likely to be stuck: enterprise networks that block analytics, air-gapped installs, privacy-conscious users. “Fewer than 2% of sessions in the last 90 days” is an honest sentence; “almost nobody uses it” is a guess wearing a percentage’s clothes.

The announcement: a date, a fate, and a way out

A platform-drop announcement answers five questions, in roughly this order:

• Which platforms, precisely. “Windows 8.1 and earlier,” “macOS 12 Monterey and older,” “Node 16 (below 18.0.0)” — exact versions, not “older systems.”
• When, as a date. “After 2026-10-01” beats “in v5,” because people on old platforms can’t always see your version numbers coming — and a date lets an IT department put it in a plan.
• What happens to existing installs. Keeps working without updates? Stops launching? Loses sync? Security fixes until when? This is the question the affected reader actually has, and most announcements skip it entirely.
• How to tell if you’re affected. One command, one menu path, one header to check. “Help → About; if it says 11.x you’re affected” converts anxiety into a ten-second check.
• The way out — all of them. Upgrade the OS; or stay on the final supported version (name it, link it, per the LTS guide say how long it gets security fixes); or, if neither is possible, what stops working and when. An announcement with no viable path for stuck users isn’t communication, it’s a countdown.

What happens to the stragglers is the real decision

Every drop implicitly chooses one of three fates for the users who don’t move, and the announcement should say which — out loud:

• Hard cutoff. A web app that adopts features old browsers lack simply breaks there. Fine — sometimes unavoidable — but then the in-band warning (below) is mandatory, because the failure will otherwise arrive as a blank page with no explanation.
• Frozen final version. Desktop apps, CLIs, and libraries can pin: v4.9 is the last release for macOS 12, it stays downloadable, and it gets security backports until a stated date. This is the kindest option and usually cheaper than teams assume — you’re promising availability, not new features.
• Degraded mode. The app runs but loses the features that need new platform APIs. Honest only if the degraded state is documented and stable, not a slow-motion breakage nobody tests.

One rule sits above all three: your update mechanism must stop offering incompatible builds. Sparkle appcasts and electron-updater feeds can gate on minimum OS version — use it. Pushing an update that installs and then won’t launch on the old OS is the cardinal sin of platform drops: you didn’t drop support, you shipped a brick. The same applies to package managers: set the engines/requires floor so old runtimes get a clear refusal at install time, not a syntax error at midnight.

Timing and in-band warnings

Lead time should scale with the reader’s cost to move, not yours: a consumer web app dropping an old browser might need 90 days; a library dropping a runtime should ride a major release with the floor announced a release ahead; anything with enterprise or on-prem customers needs six to twelve months, because their upgrade windows are quarterly and contractual.

And here’s the uncomfortable truth about the changelog: the people affected by a platform drop are the least likely to read it. They’re on old software because they don’t chase updates. So the announcement must also go in-band, where only the affected see it: a startup notice in the app on soon-unsupported OSes, a console or stderr warning when the CLI runs on an old runtime, a banner served only to old browser engines, a deprecation warning on TLS 1.1 connections. In-band warnings are precisely targeted by construction — nobody else ever sees them — and each one should link the canonical announcement. Then repeat on a schedule (announce, midpoint reminder, final month), per the announce-three-times rule, and publish a drop-day entry that links back to the original so the paper trail closes.

Is it a breaking change? (the version question)

For libraries and anything installed: yes. Raising a runtime or OS floor is a major version, full stop — unchanged code is irrelevant, because the compatibility promise changed. Burying an engines bump in a patch release is how CI fleets across the world wake up red. For evergreen SaaS there’s no version to bump, which makes the dated announcement and the in-band warning carry the entire load — the SaaS changelog is the only record the change ever happened.

Entry templates: the heads-up and the drop

## Heads-up: ending support for macOS 12 — 2026-07-01
Tag: announcement

After **2026-10-01**, new releases of Acme will require macOS 13 or later.

- **Affected:** Macs running macOS 12 Monterey or older. Check via Apple menu
  → About This Mac.
- **What happens:** Acme 4.9 (the last macOS 12 release) keeps working and stays
  downloadable. It will receive security fixes until 2027-04-01, but no new
  features. Auto-update will not offer incompatible versions.
- **Why:** macOS 13 APIs we now depend on; under 2% of active devices run
  macOS 12 (measured over the last 90 days).
- **Your options:** upgrade to macOS 13+, or stay on 4.9.
  Support policy: <url>. Questions: <url>.

## Acme 5.0 — 2026-10-01
Tag: breaking

Acme now requires macOS 13 or later, as announced in July (<link>).
macOS 12 users: version 4.9 remains available at <url> with security
fixes until 2027-04-01.

Note what the template refuses to do: no version-number-only dating, no “legacy systems,” no unstated fate for existing installs, and the drop-day entry links the heads-up — receipts, not surprises.

Six anti-patterns

• The silent floor bump. The engines field or minimum OS rises inside a patch release, labeled “chore: update deps.” It’s the platform-drop equivalent of an unannounced API removal — and it’s the most common one.
• “Please upgrade your browser.” A nag with no date, no policy link, and no statement of what breaks when. A warning that never resolves trains users to ignore warnings.
• Changelog-only announcement. Publishing the drop where only up-to-date users will read it. In-band warnings for the affected are the actual announcement; the changelog entry is the canonical record they link to.
• The auto-update brick. Dropping an OS while the updater still offers the new build there. If the update installs and won’t launch, every part of your announcement was wasted.
• Usage-stat theater. “Only 2% use it” — 2% of what, measured how, over when? If telemetry can’t see the stuck users, say so instead of citing precision you don’t have.
• Support-matrix rot. The docs say Windows 8.1 is supported; nobody has tested on it since 2023. Untested is unsupported — update the matrix or stop publishing it. A drop you’ve already de facto made deserves a de jure announcement.

Where Wakelog fits

Wakelog gives the announcement the infrastructure this guide keeps assuming: a permanent permalink for the heads-up entry — the URL your in-app banner, CLI warning, and support replies all point at — tags so the announcement and breaking entries are filterable (?tag=announcement is your live “upcoming support changes” table), scheduled publishing so the drop-day entry is written the day of the heads-up and flips live at the cutoff automatically, and RSS/JSON feeds so the fleet operators who manage stuck machines can watch for exactly these entries in their monitoring. Wakelog won’t gate your appcast or set your engines field — it’s the communication layer: the place the date, the fate, and the way out live at a URL that outlasts the platform you’re leaving behind. Free, two-minute setup.

Related guides

• How to write a deprecation policy (with template)
  Decide how you retire things before the fight starts: scope, notice windows, channels, and what “deprecated” actually means — with a copy-paste policy template.
• LTS and maintenance releases: release notes for versions you still support
  The day you cut an LTS branch, your changelog becomes a matrix. Backport entries that name origin and siblings, the support table that answers “is my version still supported?”, security coverage across every branch at once, and version EOL announcements with dates that only ever move later.
• Network upgrade notes: announcing protocol changes you can’t deploy for anyone
  Most release notes describe software somebody can deploy. A protocol upgrade only happens if enough independent operators adopt it before an activation moment — and whoever misses it falls off the network. How to write upgrade notes that coordinate strangers: heights and dates together, a version table per client, consequences stated as physics, and a campaign instead of a single post.

Last updated 2026-08-01 · All guides