Changelog archives: how long should you keep old entries?

Every changelog guide obsesses over the newest entry — how to write it, where to announce it, whether anyone reads it. This one is about the other 95% of the page: the entries from last year and the year before, the ones nobody is announcing anymore. Do they stay? Can you edit them? When is it okay to trim? The short answer is the oldest rule in record-keeping: keep everything, and design the page so the pile stays useful. The long answer is why, plus the handful of legitimate exceptions.

Old entries have readers — four of them

A changelog entry’s traffic curve looks like a spike and a long, thin tail. The spike is announcement week. The tail is small but it never reaches zero, because four kinds of readers arrive with a question only history can answer:

  • The version-jumper. Upgrading from the version they pinned two years ago to today’s. They read every entry in between, in one sitting — the CLI and library guide calls this the bulk reader. Delete a year of entries and their upgrade path has a hole exactly where the breaking change was.
  • The debugger. Someone — a user, your own support team, you in eighteen months — asking “when did this behavior change?” The changelog is git blame for product behavior. It only works if the history is complete: an absence has to mean “nothing changed,” not “we pruned that quarter.”
  • The evaluator. Prospects read changelogs backwards, skimming years of entries to answer “is this thing alive, and how do they treat users when something breaks?” An unbroken multi-year history is one of the strongest trust signals a small product can show — the examples guide makes this case with SQLite, whose decades of visible history function as marketing no campaign could buy.
  • The auditor. Procurement questionnaires and compliance reviews ask what changed and when, sometimes years later. The compliance guide covers the details; the archive’s job is simply to still exist when the question arrives.

None of these readers generate impressive analytics. All of them are doing something that matters — upgrading, debugging, buying, approving. That asymmetry — low traffic, high stakes — is the whole argument for the archive.

The default: append-only, forever

A changelog is a ledger, not a brochure. The docs vs changelog guide draws the line: docs are a snapshot you edit in place; the changelog is an append-only record of what happened. Ledgers don’t get pruned. Three practical reasons the default should be “keep everything”:

  • Permalinks are promises. Old entries are linked from support threads, migration PRs, Stack Overflow answers, and your own docs (“Changed in v2.3”). Deleting an entry 404s every one of those links, and you don’t know where they are.
  • Deletion reads as history-editing. The moment a user notices an entry they remember is gone, every remaining entry becomes suspect. You spent years building the record precisely so it would be believed.
  • Storage is free; you’re economizing the wrong resource. Five hundred old entries cost kilobytes. The scarce resource is the reader’s attention on page one — and that is a presentation problem, solved by layout, not by deleting the past.

Presentation does what deletion can’t

Every reason people want to prune — “the page is huge,” “nobody scrolls that far,” “the old stuff buries the new” — is a layout complaint wearing a retention costume. The fixes are all covered in the page design guide, but the archive-relevant ones are:

  • Paginate; don’t infinite-scroll. Recent entries on page one, numbered pages behind it. Crawlers and version-jumpers can reach 2023; casual visitors never see it.
  • Let feeds be recent. RSS and JSON feeds should carry the latest entries only — subscribers want news, not history. The archive lives on the page and in the machine-readable export, not in the feed. A 30-item feed over a 500-entry archive is correct, not a discrepancy.
  • Filters are archive views. A tag filter like ?tag=breaking is your “every breaking change, ever” page; search is “when did we touch exports?” Both make a deep archive feel organized instead of long.

Editing old entries: corrections yes, revisionism no

Append-only doesn’t mean frozen. There are two kinds of edits, and the test that separates them is simple: does the edit make the record more accurate, or does it make you look better?

Legitimate maintenance — do these freely:

  • Typos, broken links, moved docs URLs. Link rot in old entries is worth an occasional sweep; a permalink full of dead links keeps its promise in letter but not in spirit.
  • The planned two-pass edit: a hotfix stub filled in with the real explanation, or a security entry updated to link the published advisory. The entry was always meant to grow.
  • Annotation. When an old entry is superseded — a limit later raised, a feature later reworked — append a dated note to it: “Update 2026-05: this limit was raised to 100; see the follow-up entry.” The original stays; the correction is visible and dated. This is how ledgers fix errors — with a correcting line, not an eraser.

Revisionism — never:

  • Softening an old entry that aged badly (a promised feature that never shipped, a “temporary” limitation now permanent). Write a new entry that links back — the sunset guide covers walking back a public commitment honestly.
  • Renaming features throughout history to match current branding. Old entries should use the names users saw at the time; a rename entry is the bridge between the old vocabulary and the new. Rewriting history so the old name never existed breaks search for exactly the people trying to follow the rename.
  • Deleting an entry because it’s embarrassing. The incident everyone remembers is more embarrassing with a hole where the fix announcement used to be.

When trimming is legitimate: slices, not the canon

There is one honest pattern where old entries genuinely get removed — and it never touches the canonical archive. Several distribution channels are slices of the changelog with their own size constraints:

  • WordPress readme.txt conventionally carries the last 10–20 releases; the WP guide calls the pattern trim-and-archive — trim the file, link the full history.
  • App store “What’s New” fields show one release at a time by design (app store guide).
  • A CHANGELOG.md shipped in a package tarball can carry the current major only, with a first line linking the hosted archive — keeping install sizes sane without orphaning history.

The rule that keeps all of this honest: trim the slice, never the canonical. One home keeps everything forever; every constrained channel links back to it. Trouble only starts when a slice is the only copy — which is the real argument for having a canonical home at all.

Migrations and resets: carry the history with you

The most common way products actually lose their archive isn’t deletion — it’s migration. Switching changelog tools, moving domains, or relaunching “fresh for v2” and quietly leaving years of history behind on a dead URL. Treat the archive as cargo:

  • Import, don’t retype. Any tool worth switching to can ingest your existing history — the starting-a- changelog guide covers backfilling levels; the bar is that original dates survive the move.
  • Redirect the old permalinks if the URLs change. The support threads linking to them don’t know you migrated.
  • Don’t reset at v2.0. A new major is a new chapter, not a new book. The evaluator reading backwards should sail straight past the rewrite into 2022 without hitting a wall that says “history starts here.”

Anti-patterns

  • The annual purge. “Cleaned up the changelog” as a January ritual. You deleted the evidence that you ship.
  • Infinite scroll with no floor. Technically the archive exists; practically nobody — human or crawler — can reach March 2023 or link to a stable page of it.
  • The PDF graveyard. “Older entries available in the attached PDF.” Unsearchable, unlinkable, and a strong signal the archive is where information goes to die.
  • Retroactive rebranding. Every historical mention of “Workspaces” silently rewritten to “Teams.” The rename now has no seam — and no explanation.
  • The history reset. New site, new tool, new era — and the changelog starts six weeks ago while the product is six years old. Reads as either carelessness or cover-up; both lose the evaluator.
  • Trimming the only copy. Keeping “just the recent releases” in the repo’s CHANGELOG.md when that file is the canonical record. Trim a slice, never the canon.

How this works in Wakelog

Wakelog’s public pages are built on the keep-everything default:

  • No retention limits. Entries stay until you delete them; there’s no plan tier that expires your history.
  • Stable permalinks + pagination. Every entry keeps its URL forever; old entries live on numbered pages that crawlers and version-jumpers can reach. Tag filters and search give you the archive views — your entire breaking-change history is one link.
  • Slices with a canonical home. Feeds carry the latest entries; the changelog.md export carries everything, in a format our own importer round-trips — so the full archive is portable the day you migrate in or out. Import preserves your original dates, so a backfilled history reads as history, not as a bulk paste.

Start your changelog — free   Next: changelog page design →

Related guides

Last updated 2026-07-29 · All guides