How to Announce End of Life for Open Source Software

Announcing end of life for open source software means telling users when a version, product line, platform, or entire project will stop receiving fixes or support. The announcement should make scope, dates, security handling, download status, and migration options explicit.

EOL communication is not a legal or security guarantee. It is a user-risk communication tool. Maintainers should avoid implying that unsupported code remains safe, patched, or monitored.

Define what is ending

End of life can apply to different things: one version branch, one operating system, one package format, one feature, one hosted service, or the whole project. The announcement should name the exact scope.

Do not make users infer scope from vague wording such as "this project is deprecated." If only version 2.x is ending, say that. If the whole project is archived, say that. If a feature is deprecated but the project continues, link the deprecation guidance instead of calling the whole project EOL.

Scope is the first safety detail because users need to know whether they are affected.

EOL, end of support, and archival

End of life often means no further fixes are planned. End of support may mean no help, patches, or security response for a version. Archival usually means the repository or project is kept as a historical record and is no longer actively maintained.

Use the term that matches reality. A project can be EOL but still downloadable as historical source. A version can be unsupported while the project continues. A repository can be archived on a platform while package registries still show older artifacts.

If the project uses more than one term, define them in the announcement.

Set dates and final support scope

Users need dates. State the announcement date, final planned release if any, final support date, and when security fixes stop. If a date is uncertain, say what condition controls the decision.

Avoid unrealistic grace periods. If maintainers cannot patch an old branch for six months, do not promise it. If support ends immediately because no maintainer can continue safely, explain that directly.

For widely used software, give as much advance notice as capacity allows. Users may need time to migrate, update packaging, notify downstreams, or replace integrations.

Explain security handling carefully

Security language should be precise. Say which versions receive security fixes, which do not, and where vulnerability reports should go. If the project cannot review reports after EOL, do not leave an active-looking security process in place.

Unsupported software can still contain vulnerabilities. Do not say old software is safe because no reports are known. A better statement is that maintainers do not plan to assess or patch that version after the EOL date.

If a final security release exists, identify it and tell users what action is expected. If no fix is planned, direct users to migration or risk evaluation rather than implying continued support.

Update the places users rely on

An EOL notice should appear where users find the project:

• README and project website;
• release notes and changelog;
• package registry descriptions;
• documentation home page;
• download pages and archived packages;
• security policy;
• issue templates and support channels;
• repository description or archive banner where supported.

GitHub's repository archival behavior makes repositories read-only and signals lack of active maintenance, but platform archival alone is not enough. Users may arrive through package managers or old documentation.

Migration, forks, and alternatives

If a migration path exists, name it. That might be a newer major version, a replacement package, a maintained fork, a new project, a commercial successor, or an export path. Do not invent alternatives or endorse a fork the project has not evaluated.

If no recommended migration exists, say so. Users can still evaluate options, but they should not mistake silence for hidden support.

For forks, explain whether the fork is official, community-maintained, or simply a possible continuation under the license. Trademark and package-name questions may matter if the fork uses similar identity.

Download and package status

EOL does not always mean files vanish. Historical downloads may remain available for reproducibility, older systems, or archival use. The key is labeling. A historical package should not look like the current recommended release.

Package registries can be tricky because old packages may remain installable. Update descriptions, deprecation messages, README badges, and release notes where the platform allows it.

Do not remove artifacts abruptly if users need them to migrate or reproduce old work unless there is a security or legal reason. Labeling is often safer than silent disappearance.

Announcement template

A practical EOL announcement can include:

• project or version affected;
• announcement date;
• final supported release;
• final support date;
• security-fix policy after that date;
• package and download status;
• migration path or statement that none is recommended;
• fork or archive status;
• issue/support-channel changes;
• contact path for security-sensitive concerns before support ends.

Keep the announcement factual. Users need decisions, not apologies disguised as unclear promises.

Timing the announcement

Give users enough notice when the project can. A library used in production, a desktop app with saved data, or a package distributed by downstream maintainers may need more time than a small experimental tool.

Notice periods should reflect capacity. If no maintainer can safely provide six months of fixes, do not promise six months. Instead, state the final date and explain which reports, if any, will still be reviewed before then.

For urgent EOL caused by security, infrastructure, or maintainer availability, explain the practical reason without exposing private details. Users need to know what action to take more than they need a long backstory.

Handling package managers and mirrors

Users may install old software through package managers, containers, app stores, archives, or downstream builds long after the main repository changes. Update the channels the project controls, and give downstream packagers a clear status note they can carry forward.

If the project cannot update a downstream package, link an upstream EOL notice from the project website and release notes. That gives packagers a canonical source to reference.

Avoid direct binary deletion as the only signal. A missing file may look like an outage rather than an end-of-life decision. Clear labels are usually safer.

Support after EOL

After EOL, maintainers should decide what happens to issues and discussions. Options include closing the tracker, leaving it read-only, moving questions to community discussion, accepting migration documentation, or accepting security reports only for a final transition period.

The chosen path should match capacity. If issues remain open but no one responds, users may assume support still exists. If everything closes instantly, users may lose migration knowledge that could help others.

For archived repositories, remember that platform archive state can make issues and pull requests read-only. Update docs before archival when possible.

Example EOL wording

A concise notice might say: "Version 3.x reaches end of support on 2027-03-31. The final planned 3.x release is 3.8.4. After that date, maintainers do not plan bug or security fixes for 3.x. Users should migrate to 4.x. Historical 3.x downloads may remain available, but they are not recommended for new installations."

That structure covers scope, date, security expectation, migration, and archive status. The exact wording should fit the project, but the decision points are consistent.

If there is no replacement, say so directly: "No maintained successor is recommended by the project." That is better than sending users toward an unevaluated fork.

EOL for one version versus the whole project

A version EOL notice should point users toward the maintained branch. It should keep the current project identity active and make clear that only older releases are ending.

A whole-project EOL notice is stronger. It should explain whether maintainers will still review security reports, accept forks, keep downloads available, or archive repositories. It should avoid roadmap language that implies future feature work.

A platform EOL notice sits between these cases. If macOS packages, 32-bit builds, or a specific runtime are ending, name the platform and explain whether source support continues.

Coordinating with downstreams

Downstream packagers, distributions, plugin authors, and large users may need advance notice. They may carry patches, publish packages, or support users who never read the upstream repository.

For projects with downstreams, publish an issue or discussion that packagers can link. Include the final supported version, final date, and whether downstream maintenance is independent.

If downstreams continue a version after upstream EOL, users need to know that support belongs downstream. Upstream should not appear to promise fixes it no longer controls.

Avoiding accidental current signals

After EOL, remove or revise badges, "actively maintained" claims, roadmap links, download buttons, and support forms that suggest current support. Update metadata where possible.

Old pages can stay useful when labeled as historical. The problem is stale current-language, not archival availability.

Search users may land on old docs first, so put status notices near the top of important pages rather than only in a final blog post.

Security exceptions after EOL

Some projects choose a short security-only window after general support ends. If so, define it carefully. State which versions qualify, which kinds of reports are considered, when the exception ends, and whether fixes are guaranteed or only considered.

Do not use "security-only support" as vague reassurance. Users may interpret it as broad maintenance. If maintainers will review reports but not guarantee patches, say that directly.

When the exception ends, update the security policy and EOL notice so reporters do not rely on stale language.

EOL and forks

Open source licenses may allow forks after EOL, but users still need clarity. A fork may continue development, but that does not make it official unless the project transfers authority or says so.

An EOL announcement can say whether maintainers know of a successor, whether forks may be listed later, and whether the original name or logo can be used. Trademark policy matters here because a fork that looks official can confuse users about support and security.

If no fork is endorsed, avoid hinting that one exists. Users can evaluate forks independently, but the project should not create false confidence.

Final release notes

A final release deserves careful notes. It should explain whether it is the last supported build, what fixes it contains, whether migration is required, and how users can verify they are on the final version.

If the final release is mainly a notice update, say that too. Users should not install a final package expecting new features unless the notes say they exist.

Good final release notes make the historical record easier to understand later.

Maintainer workload after the notice

An EOL announcement can briefly increase work. Users ask whether they are affected, downstream packagers request clarification, and security reporters may test whether the old path still responds.

Plan a short follow-up period if possible. Assign someone to answer scope questions, update confusing docs, and correct package metadata. After that period, enforce the new support boundary consistently.

If maintainers cannot handle a follow-up period, publish a more complete notice at the start so fewer questions need individual replies.

The notice should also identify who, if anyone, can correct factual errors in the EOL page after support ends.

That prevents stale migration or security wording from lingering unowned.

If no one will monitor the page, say that plainly. Users can then treat the notice as a historical record rather than a support channel.

EOL announcement table

EOL communication checklist

Before publishing:

1. The affected scope is unambiguous.
2. Dates and final release status are visible.
3. Security handling is honest and does not overpromise.
4. Download and package locations are labeled.
5. Migration or fork information is included only when known.
6. Issue templates and support channels match the new status.
7. Changelog and release notes link the notice.
8. Archive banners or README notices are added where relevant.
9. Users can tell what is historical versus current.

Responsible EOL communication respects users by making limits visible. It is better to say "this is no longer maintained" clearly than to leave old software looking safer or more supported than it is.