Take end-of-life dates from the project's own policy page, store the link and the date you checked, and treat third-party trackers as a pointer. Dates move and status labels lag, so a copied date without a source is the most common reason lifecycle columns go wrong.
The case for the upstream page
The maintainer decides what is supported. A tracker summarizes that decision, usually well, but it can lag or differ in how it defines a term. Three cases from our own fetches on 19 October 2026 show why you want the original.
A label that disagreed with its own dates. The Debian releases page lists Debian 11 Bullseye with an end of LTS date of 31 August 2026, yet the status text beside it still said "under LTS support". The date had passed and the label had not been updated. Someone who read only the label would conclude it was covered.
A date that moved several times. GitHub's changelog on Node 20 for Actions runners carries editor notes that changed the removal date more than once, with the latest note setting it to 23 September 2026. A date copied from an earlier version of that page would be wrong.
A date marked as expected. The Ruby branches page lists the end of life for Ruby 3.3 as expected on 31 March 2027. The word "expected" tells you the maintainers do not treat it as fixed. A tracker may drop that nuance.
A source hierarchy you can write down
- The project's own policy or release page.
- The vendor's lifecycle or roadmap page, for commercial products.
- A release announcement or changelog that states a date.
- A tracker, for discovery and cross-checking only.
Record which level each row used. A row sourced at level 4 should carry a "confirm" flag until someone checks level 1 or 2.
Fields to store with every date
| Field | Why |
|---|---|
| End date as stated | The number you act on |
| Phase the date ends | Security only ends differently from active support |
| Source URL | So a reviewer can check |
| Date checked | Proves recency |
| Confidence | Stated, expected, or tracker only |
The check date is the one most teams skip, and it is the most useful when a customer or auditor asks how current the list is.
How often to recheck
Link the cadence to the date. If the end date is within 90 days, recheck monthly, because plans shift as deadlines approach. If it is further out, quarterly is usually enough. A fixed calendar review also catches new releases that change which versions are supported. A quarterly end-of-life check is a ready routine, and tracking support windows without spreadsheet rot covers storage.
When there is no stated date
Some small libraries publish no policy. Mark them Unknown, and use activity signals as a secondary input: recent releases, open security issues, a named maintainer. Is the dependency abandoned discusses what those signals can and cannot show. Do not turn a guess into a date.
Try it yourself
Click through it at your own pace, or open it full screen. Note how a monitoring view stays current by rechecking, which is the habit a lifecycle column needs.
Where Safeguard fits
Safeguard's SBOM and dependency scanning supplies the list of components, and compliance and evidence automation can hold the source links and check dates as evidence. Try the free scan at gold.safeguard.sh/scan.
Quick check
Can I use a tracker at all?
Yes, to find dates and cross-check. Confirm on the project's page before you rely on a date.
What if the upstream page and the tracker disagree?
Follow the upstream page, note the disagreement, and recheck later.
Sources
- Debian releases
- GitHub changelog: Deprecation of Node 20 on GitHub Actions runners
- Ruby maintenance branches
Last reviewed: 19 October 2026.
