Retire a fork when upstream has absorbed your changes, when your patch list is small enough to carry another way, or when keeping the fork costs more than it returns. Write those conditions down the day you fork, because forks created for a quick fix tend to outlive the people who made them.
Forks drift into permanence
Nobody plans a permanent fork. A bug blocks a release, someone copies the library, patches it and moves on. The patch works, the ticket closes, and the fork becomes part of the product. Two years later it is behind upstream, nobody knows who owns it, and an advisory arrives for a version it resembles.
Exit criteria fix this by turning "temporary" into a checkable statement.
Five exit triggers
| Trigger | How to check | Next step |
|---|---|---|
| Upstream merged your change | Compare the release notes and the fix commit | Move to the upstream release, drop the fork |
| Upstream shipped an equivalent fix | Read the changelog and diff | Replace your patch with theirs |
| Your patch list fell to one or two | Count commits ahead of upstream | Switch to a patch queue. See patch queue or long-lived fork |
| The fork is far behind and unowned | Measure divergence and ask for an owner | Assign an owner or retire |
| Upstream is archived or abandoned | Check project status | Decide whether to adopt it. See what an archived upstream means |
Write the exit on day one
In the fork's README or provenance file, add three lines:
- Why this fork exists, in one sentence.
- The condition under which we stop. For example, "when upstream releases a version containing the path traversal fix."
- The owner and the review date.
Put the review date in a calendar. When it arrives, someone answers one question: does the reason still hold?
How to retire it safely
- Confirm the target upstream version contains every patch you still need. Use the ancestry and equivalence checks.
- Port any leftover behavior differences into your own code, not into the library.
- Switch the manifest back to the published package, and remove replace or override lines.
- Run tests and a fresh dependency scan, and check that the license and notices are still handled. See what notices to keep.
- Update your SBOM and fork register.
- Archive the fork rather than deleting it, so history is available for audits. GitHub's archive feature makes a repository read only and signals it is no longer maintained.
When not to retire
Keep the fork when upstream has rejected your change for good reasons and you need the behavior, or when you have decided to own the code as part of your product. Then make that a decision, with an owner, budget for syncing and a security review cadence. See forking strategy for enterprise open source.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can show which components your builds still pull from non standard sources, a useful list when you hunt for forks to retire. Try a free scan at gold.safeguard.sh/scan.
Quick check
What is the most common reason forks outlive their purpose?
No one wrote down when to stop. Without an exit condition and an owner, a temporary fix becomes permanent by default.
Should I delete a retired fork?
Usually archive it. An archived repository is read only and keeps the history that audits may ask about.
Sources
Last reviewed: 19 October 2026.
