Publish a dated schedule, name the phases, and announce the final security fix date well before it arrives. Update your SECURITY.md supported versions, mark releases in the changelog, and tell users which version to move to. Silence is the worst option.
A published schedule is the model to copy
The Python developer guide keeps a status page of Python versions. It shows a table with each branch, its status, first release date and end of life date. The statuses it uses include feature, bugfix, security and end-of-life, and it notes that dates shown in italics are scheduled and can be adjusted. The same page links to a chart of older versions.
You do not need Python's scale. The useful parts are the named phases and the stated dates.
Define your phases
| Phase | What you promise |
|---|---|
| Active | New features and bug fixes |
| Maintenance | Bug fixes only |
| Security only | Fixes for vulnerabilities only |
| End of life | Nothing, upgrade |
Pick words that fit your project, but define each in one sentence in your docs.
Steps
- Decide the date and write it down, with a review point.
- Announce it early on the places users read: release notes, repository, mailing list or blog.
- Update SECURITY.md so the supported versions table matches. See supported versions table in SECURITY.md.
- Ship a final release for the line, with a clear note that it is the last, and what to move to.
- Mark the old line in registries where possible, for example with a deprecation message. See what an npm deprecation message should say.
- After the date, stop backporting and say so if someone reports a flaw in the old line. A published refusal is kinder than a silent one.
What to say about security after end of life
State that new vulnerabilities in the ended line will not be fixed, and that users who stay accept that risk. Note that scanners may show no advisory for an old line simply because nobody is looking, which is not evidence of safety. Our post on end of life software and scan results explains.
Helping users move
- Write an upgrade guide covering breaking changes.
- Offer a deprecation period with warnings in the old line before it ends.
- Be explicit about the oldest version still receiving security fixes today.
A short announcement template
A good announcement is only a few lines. It names the release line, states the date of the last security fix, says which version users should move to, links to the upgrade guide, and links to the updated supported versions table. It also says what happens after the date: no further fixes, even for serious issues. Post it where users already look and repeat it with each release of the old line until the date passes. If the date moves, post the change as prominently as the original, so nobody plans around stale information.
Quick check
How much notice is fair?
There is no universal number. Match it to how long users take to upgrade, and state it. Python's public schedule shows end dates years ahead.
Can I extend the date later?
Yes, and the Python page notes that scheduled dates can be adjusted. Announce any change as clearly as the original.
Sources
Last reviewed: 19 October 2026.
