Keep one list of support end dates

How to do it

Inherited code often runs a version that stopped getting fixes years ago, so every hole found since then stays open. Take each date from the project's own release page, such as the Node.js release schedule or the Python version status page. Read the version in use from the lock file, the container image and the hosting settings, not from memory. The runtime rule is Leave runtimes that are out of support. Databases follow Upgrade the database before its support ends, and managed engines follow Upgrade managed engines before standard support ends.

Examples

JavaScript example

import { readFileSync } from 'node:fs';

const WARNING_DAYS = 180;
const DAY_MS = 24 * 60 * 60 * 1000;
const entries = JSON.parse(readFileSync('support-dates.json', 'utf8'));
const late = entries.filter(entry => new Date(entry.endOfSupport) - Date.now() < WARNING_DAYS * DAY_MS && !entry.upgradeTicket);
if (late.length) { console.error(late.map(entry => `${entry.name} ${entry.version} ends ${entry.endOfSupport}`).join('\n')); process.exit(1); }

Python example

import json, sys
from datetime import date, timedelta

WARNING = timedelta(days=180)
entries = json.load(open("support-dates.json"))
late = [e for e in entries if date.fromisoformat(e["endOfSupport"]) - date.today() < WARNING and not e.get("upgradeTicket")]
if late:
    sys.exit("\n".join(f"{e['name']} {e['version']} ends {e['endOfSupport']}" for e in late))

How to check

A build step reads the list and fails when an entry's end date is within 180 days and the entry has no upgrade ticket. No entry's end date is in the past.

Sources

• Node.js releases
• Status of Python versions

Related rules

• STK-15 Leave runtimes that are out of support in Software choices
• DAT-58 Upgrade the database before its support ends in Data and databases
• INF-60 Upgrade managed engines before standard support ends in Infrastructure and environments