EOL Dates Drift: What We Found Cross-Checking 54 Products Against Their Vendors
An end-of-life date looks like the most stable fact in software: the vendor announces it, everyone writes it down, and the clock runs out on schedule. In practice, EOL dates drift. Vendors revise them after release. Projections get published before vendors commit, then harden into "facts" as they're republished. Schedules slip by a patch release or two. Placeholder values sneak into datasets and look exactly like real dates. And everyone downstream — aggregators, dashboards, compliance tools, us included — inherits whatever the date was on the day they copied it.
This isn't anyone's failure. It's the natural physics of an ecosystem where thousands of dates flow from hundreds of vendors through shared open data into countless tools. endoflife.ai is proudly built on the open-source endoflife.date project — the community effort that made lifecycle data freely available in the first place, and without which sites like ours wouldn't exist. Shared data means shared drift, and it also means shared fixes: when systematic verification finds a confirmed discrepancy, correcting it upstream fixes it for everyone. So we ran the verification, and this is what we found.
The Method: Primary Sources Only, With an Honest "Unconfirmed" Tier
In July 2026 we cross-checked 54 products across 8 vendor families against official vendor lifecycle documentation — Microsoft lifecycle pages, Oracle's lifetime support policy PDF, Red Hat's lifecycle tables, project release policies, and the like. No secondary sources, no other aggregators: if the vendor didn't publish it, it didn't count as confirmation.
That last rule forced a category most datasets don't have. The results:
| Outcome | Products | Meaning |
|---|---|---|
| Fully verified | 33 | Every checked date matches the vendor's official documentation |
| Corrected | 12 corrections | Discrepancies confirmed against the vendor and now published on our pages with sources |
| Honestly unconfirmed | 7 | The vendor publishes no per-version dates, so no date can be "verified" |
| Structural review | 3 | The mismatch isn't a date — it's how the product's lifecycle is modeled |
The unconfirmed tier deserves emphasis, because it's the one that usually gets papered over. React, Docker Engine, nginx, Redis, GitLab, Jenkins, and WordPress publish no per-version end-of-life dates at all. They publish policies — typically some form of "the latest release is supported, older ones aren't" — and every calendar date you've ever seen for those products is a derivation from that policy, made by someone downstream. Some derivations are careful and anchored to real release dates. But they are not vendor commitments, and presenting them as if they were is itself a form of drift.
What Drift Actually Looks Like: A Taxonomy
The corrections and discrepancies weren't random. They sorted cleanly into five failure modes, each with a clear specimen.
1. Post-release revisions
Vendors publish projected lifecycle dates before a product ships, then adjust them once the general-availability date is real. Windows Server 2025 is the textbook case: Microsoft's lifecycle page now lists an extended end date of November 14, 2034, aligned to the actual November 2024 GA — about five weeks later than the pre-GA projection of October 10, 2034, which is the date that still persists in community data. Nobody made an error; the date simply moved after everyone copied it.
2. Placeholder dates
When a vendor announces a year but not a day, "2030" has to be stored as something — and January 1 is what it becomes. CentOS Stream 10 carried an EOL of January 1, 2030 in community data, while the CentOS Project's own download page lists May 31, 2030, the end of the corresponding RHEL 10 full-support phase. A serialization artifact, five months of error, indistinguishable from a real date unless you check.
3. Schedule slips
Even officially scheduled dates are schedules, not history. Kubernetes 1.31 was slated to reach end of life on October 28, 2025 — but the actual EOL landed on November 11, 2025, two weeks later, with a final 1.31.14 patch. Data captured from the schedule is subtly wrong forever after; data captured from the outcome is right.
4. Projection hardening
The subtlest mode. A date computed from policy — release date plus the policy's support window — gets published without a label, republished without context, and after a few hops reads as an announcement. Angular 21's end date is a clean example: our published date follows Google's stated 18-month policy exactly, but the official release table lists the LTS end as still to be announced. Ruby 3.4 and 4.0 carry firm-looking dates upstream of us that ruby-lang.org has never committed to. Even kernel.org flags its own longterm-branch EOL projections as "not set in stone." Projections are legitimately useful — the fix isn't to delete them, it's to label them.
5. Supersession conventions
For the seven no-published-dates products, the "EOL date" in circulation usually means the day the next version shipped. That's a reasonable editorial convention, but it measures "no longer the newest," not "no more patches" — WordPress, for instance, shipped a security update for a branch two months after that branch's supposed supersession EOL, because its security team backports fixes as a courtesy. A date can be internally consistent and still mean something different from what the reader assumes.
Verification Caught Our Own Bugs Too
We'd like to pretend the audit only found problems elsewhere. It didn't. Our page template once inverted supported/EOL labels for products whose upstream data encodes end-of-life as a boolean rather than a date — exactly wrong, in both directions. Our risk score under-warned an entire category until verification exposed the gap. And the audit caught our summary strings contradicting our own version pages — one product's overview claimed a range of versions was supported while the pages beneath it correctly showed several already past EOL. If you republish lifecycle data — and we do, at scale — you drift too. The only honest posture is to assume it and build the checking in.
What We Changed
- Provenance lines. Verified pages now say what was checked, against which vendor source, and when.
- A corrections layer. Confirmed vendor dates are applied as explicit, sourced overrides on top of upstream data — visible corrections, not silent edits.
- A public accuracy page. The /accuracy page documents the methodology, the tiers, and the current tallies.
- Machine-readable results. The full verification dataset ships at /verification.json, so you can audit us the way we audited the data.
Fixes Flow Upstream — and They Landed
Because we're built on endoflife.date's open data, confirmed findings don't stop at our pages — we contribute them back upstream, with vendor sources attached, so the whole ecosystem inherits the correction instead of the drift. On July 21, 2026, the endoflife.date maintainers reviewed and merged all six of the correction PRs we filed from this audit, covering five of the specimens above:
- #10519 — Windows Server 2025 revised Microsoft lifecycle dates (the post-release revision)
- #10520 — CentOS Stream 10 end date May 31, 2030 (the placeholder date)
- #10521 — Kubernetes 1.31/1.30 actual EOL dates (the schedule slip)
- #10522 — Ruby 3.1's actual EOL per ruby-lang.org
- #10523 — Go 1.24 EOL aligned to the Go 1.26 release
- #10524 — Veeam Backup & Replication v13 EOL, November 2028 (a date the vendor published that hadn't propagated)
Every tool, dashboard, and AI assistant that reads that dataset now inherits the corrected dates. (Our MariaDB 12.3 finding is filed separately as issue #10508.) That's the deal that makes open lifecycle data work: the community project gives everyone a shared foundation, and everyone who verifies against primary sources owes their findings back to it. Drift is a commons problem; so is the fix.
What You Should Do With This
The practical lesson isn't "distrust EOL data" — 33 of 54 products verified exactly, and the ecosystem's data is good and getting better. The lesson is that dates are living values, and anything that freezes them goes stale:
- Never trust a year-old export. A spreadsheet of EOL dates from last year contains every revision, slip, and correction that happened since — silently.
- Check against a live source. The version checker answers the immediate question for any product and version.
- Get told when dates approach — or move. EOL Watch alerts you before the products you run reach end of life.
- Gate CI on live data, not a copied constant. One call tells your pipeline the current truth:
curl https://api.endoflife.ai/v1/status/kubernetes/1.31
- Bridge deliberately when a date arrives before you're ready. Extended support options can buy patched time on an EOL version while a migration finishes — a bridge with an end date, not a destination.
Every date on endoflife.ai now tells you where it came from. When you find one that's drifted — and eventually you will, because that's what dates do — tell us. It'll get checked against the vendor, corrected with a source, and sent upstream where it fixes more than just our pages.
Frequently Asked Questions
How accurate are published software end-of-life dates?
Mostly accurate, but drift is real: of the 54 products we cross-checked against official vendor documentation in July 2026, 33 verified exactly, 12 dates needed correction (now published with sources), 7 products have no vendor-published per-version dates to verify against, and 3 needed structural review. Any date worth acting on is worth checking against a live source.
Why do some vendors publish no end-of-life dates?
Projects like React, Docker Engine, nginx, Redis, GitLab, Jenkins, and WordPress publish a support policy instead — usually some variant of "only the latest release is supported." A version's effective end of support is the day its successor ships, so any specific calendar date you see for these products is a downstream derivation, not a vendor commitment.
What is a projected EOL date, and why does it matter?
A projected date is computed from policy (release date plus the support window) before the vendor announces a real one. Projections harden as they're republished: Angular 21's end date is officially still to be announced, Ruby's current branches have no committed EOL dates, and kernel.org describes its own longterm projections as changeable. A projection presented as a fact is the most common form of drift.
How do I make sure the EOL dates I rely on are current?
Don't freeze them. Check versions on demand with the checker, subscribe to EOL Watch for the products you run, and gate CI on the live API rather than a copied constant. Our verification results are public at /verification.json, with the methodology on the accuracy page.