Reading vendor support dates: upstream, host, scheduled and final are different things

Four dates that get confused

A support date can mean the vendor will stop issuing fixes, your host will stop offering the runtime, a customer will stop accepting the version in a questionnaire, or simply that someone read a page on a particular day. These are different dates with different owners. The vendor's date is public; the host's is in the host's documentation or support; the customer's is in the contract or questionnaire. Record all that apply and the day you read each.

• Upstream date: the vendor's own page.
• Host date: ask the host, in writing, for the runtime you use.
• Requirement date: the customer or policy that names a version.

Same idea, different publication

Vendors publish support information in different forms. Node.js publishes a table of release, LTS, maintenance and end-of-life dates per line and says the dates are subject to change. The Python developer guide marks scheduled dates in italics and says they may change. Rails states a rule, bug fixes for one year and security fixes for two years after a series' first release, and lists the resulting dates for the supported series. Ruby lists some end-of-life dates as expected and others as TBD. PostgreSQL supports each major version for five years after its first release. Oracle's MySQL notice speaks of moving a version to a sustaining-support tier, not of end of life, and its upgrade advice depends on the version: 8.0 for 5.7, and 8.4 LTS or 9.7 LTS for 8.0. Convert none of these into your own words without the source.

• An expected or scheduled date is a plan, not a promise.
• A tier name such as sustaining support has its own meaning on the vendor's page; read it there.
• If a vendor publishes no date, say so in the record instead of inventing one.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

component | published as                       | checked on
Node 20  | end of life 2026-04-30            | 2026-10-11
Python 3.10 | end of life 2026-10-01         | 2026-10-11
Ruby 3.2 | end of life 2026-04-01            | 2026-10-11
Rails 8.0 | security fixes through 2026-11-07 | 2026-10-11
PostgreSQL 14 | final release 2026-11-12      | 2026-10-11

What to record

For each runtime, framework and major dependency, write down the version you run, the vendor's published status, the link and the day you looked, and who confirmed the host's date. A date without a source is a rumour; a source without a day is stale the moment it changes. The record also needs the question you were asking: end of fixes, end of host support or a customer requirement, because the answer decides how urgent the work is.

• Keep one row per component in a file that you can sort.
• Re-read each vendor page before acting on a date that is more than a few weeks old.

What a date does and does not tell you

A date tells you when upstream fixes are scheduled to stop. It does not rate how risky your current version is today, say whether a particular problem has a fix or provide any security, legal or compliance conclusion. It also does not say how big the upgrade is. Use dates to set the order and the deadline, and use tests to judge the size of each step.

• Do not treat a distant date as permission to ignore small updates.
• Do not treat a passed date as proof of a breach.

How the paid outcomes use this

The inventory and plan job records every runtime, framework and direct dependency with the vendor's published status, a link and the day it was checked, or says plainly that no date is published, and a second reviewer checks each date against the vendor's page. The monthly keep-supported service re-checks them and tells you at least six months ahead when a published end-of-support date is near, with a quote for the matching one-off job. Prices are untested proposals and payment follows the agreed checks. Send versions and the host's notice, not code or keys.