Practical guide

Keep a revision log that helps old and new buyers

Last materially reviewed 2026-09-27

Quick answerRecord what changed, which files changed and who needs the correction; a new date alone is not enough.
What to know

Describe the change in plain language

A useful entry names the affected section or file and explains the practical consequence. Distinguish a typo, a clarification and a change that affects the buyer’s result. Avoid a vague improved version label that leaves readers unsure whether they need to stop working or replace a file.

What to know

Bind the entry to the package

Record the public version, file names and release date together. If several formats are affected, list them separately. Keep the earlier release in a private archive so support can understand what an older buyer saw. Do not rewrite history to make a correction look as though it was always present.

What to know

Identify the audience

Not every catalogue customer needs every update. A correction might affect one option, language or product. Use that scope to decide which legitimate notification and support routes apply. Avoid treating a purchase as blanket permission for unrelated marketing.

What to know

Make the next action clear

Tell the buyer whether to replace a file, read an added note or contact support about a specific issue. Do not claim every buyer received the notice merely because it was sent. Keep notification evidence separate from the existence of the corrected package.

What to know

An original working example

A fictional entry might say: “Version1.1 clarifies the order of two assembly steps in Instructions; the print layout is unchanged; buyers using1.0 should read the corrected paragraph before continuing.” This communicates consequence and scope without claiming the pattern was retested. Your actual entry should be reviewed by someone qualified for the craft-specific change. Avoid vague “minor update” labels when the effect is important. Keep the publication date separate from the date a problem was reported. If an investigation later changes the explanation, append a correction to the record rather than erasing the earlier account of what was known.

Continue when useful

Next: Triage a reported pattern error before replacing every file

Identify the affected version and consequence, then choose the smallest safe correction with an appropriate expert review.

Open Triage a reported pattern error before replacing every file →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Digital product variants — Merchant documentation · help.payhip.com · Merchant-controlled · checked 2026-09-27
  2. Email updates — Merchant documentation · help.payhip.com · Merchant-controlled · checked 2026-09-27