Deleting a changelog entry, and why archiving is the option instead
A changelog is a record, and deleting from a record is how history stops being trustworthy. Here is what archiving does instead, and what it deliberately cannot undo.
There is no delete for a changelog entry in Market4. The retirement is an archive, which moves the entry to the ARCHIVED status, freezes its text against any further edit, and — if it was published — takes it out of the public feed and triggers a sitemap resubmission. The row survives, the wording survives, and the fact that this announcement was once made survives. What stops is the entry appearing to readers as current.
Archiving a changelog entry is one status change with two consequences. The first is that the entry stops being editable: any attempt to update it afterwards is refused with the message that archived changelog entries cannot be edited. The second depends on where the entry was. Only a published entry was ever in the public feed, so archiving a draft changes nothing a crawler could have seen, and the product does not run the after-archive hook for it at all. Archiving a published entry does run it, because a page that was in a sitemap has to be taken back out of one.
| Status before | Editable after archiving | Was it public | Sitemap work on archive |
|---|---|---|---|
| DRAFT | No — frozen | Never | None; nothing was ever listed |
| PUBLISHED | No — frozen | Yes | The archive hook runs |
| ARCHIVED | Already frozen | Depends where it came from | Refused — already archived |
Archiving an entry that is already archived is refused rather than treated as a no-op, with the message that the changelog is already archived. That refusal is worth having: a repeated archive from a script is usually a sign that something is looping, and answering it with a cheerful success hides the loop.
A changelog entry is frozen once archived because an archive whose contents can still be rewritten is not a record of anything. The point of keeping the row rather than deleting it is that somebody can later ask what was announced, when, and in what words — and an editable archive answers that question with whatever the last person to touch it preferred. Editing is allowed on drafts and on published entries, where the text is still the current statement; it stops at the point where the entry becomes history.
The permissions differ across the same boundary. Editing a changelog entry is open to any member of the organisation. Archiving one requires an admin. That asymmetry says something plain about which action the product treats as consequential: fixing a typo in a published note is routine, and removing a note from the public record
Somebody deciding whether to buy your product reads the changelog for something your marketing pages cannot tell them: whether anyone is still working on it, and what happens to them when something changes.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Archiving a changelog entry does not reach anything that has already left the building. A subscriber email sent when the entry was published is in inboxes and stays there. A feed reader that fetched the RSS or JSON feed before the archive holds its own copy. A search engine that crawled the page may keep showing it until it recrawls. Archiving is a statement about what the site presents from now on, not a recall.
This is the reason the subscriber blast on a changelog entry sits behind its own approval in Market4 rather than riding along with the publish. Publishing is reversible in the sense that matters here — you can archive it — and an email is not reversible in any sense at all, so the two are separate decisions with separate gates.
Edit a changelog entry when the announcement is still true and the words were wrong. Archive it when the announcement itself is no longer something you want on the record as current — a feature that shipped and was withdrawn, a release that was rolled back, an entry filed against the wrong product. The test is not how embarrassing the entry is; it is whether a reader arriving today would be misled by finding it in the feed.
The four changelog tags in Market4 are NEW, FIX, IMPROVEMENT and REMOVED, and the last of those is what makes the second case above work properly. A withdrawal announced as a new entry tagged REMOVED reads as a decision. A withdrawal handled by quietly deleting the original reads, to anyone who saw it, as a product that edits its own history.
No. The changelog surface has no delete operation at all. Archiving is the retirement: it sets the entry to ARCHIVED, freezes it against further edits, and removes a published entry from the public feed. The row and its wording stay in the database, so the record of what was announced and when is preserved even after the entry stops being shown.
Because an archive that can be rewritten is not a record. The whole reason for keeping the row instead of deleting it is so somebody can later see what was announced and in what words. Editing stays available on drafts and on published entries, where the text is the current statement; the freeze applies at the moment the entry becomes history. The refusal message is that archived changelog entries cannot be edited.
No. A subscriber email sent at publish time is already delivered and cannot be pulled back by any later action in the product. This is why the subscriber blast sits behind its own approval rather than happening automatically on publish: publishing can be undone by archiving, and an email cannot be undone at all, so they are treated as two separate decisions.
Archive the original entry so it stops appearing as current, then publish a new entry tagged REMOVED describing the withdrawal. That leaves a readable trail: the announcement happened, and so did the reversal. Silently removing the first entry leaves anyone who read it with no explanation, and leaves your changelog looking like something that gets edited after the fact.
An organisation admin. Editing an entry is open to any member, but archiving requires the higher role, because taking a published note out of the public record is a heavier action than correcting one. Attempting to archive an entry that is already archived is refused with a message saying so, rather than quietly succeeding — a repeated archive usually means something upstream is looping.
A changelog migration is four decisions, not a copy and paste: where the entries live from now on, what address each one answers at, what happens to the links people already shared, and who writes the next entry.
A changelog entry that links well converts better than one that sells. The rule is destination, not persuasion: link where the reader goes to use the thing, and cut every link that exists to move them somewhere you wanted them.