Practical guide

Release a correction without leaving two competing finals

Last materially reviewed 2026-09-29

Quick answerGive the correction a clear release identity and explain exactly what it supersedes; silently replacing files can obscure what a client already downloaded.
What to know

Identify the changed scope

State whether the correction affects one file, one group or the entire release. Keep the previous version distinguishable in your private record. A change called small may still matter to someone who has already sent a file to production. Do not rely on the client noticing a modified timestamp or a different file size.

What to know

Use a clear revision note

Name the corrected release and the reason in plain language. Explain which earlier files should no longer be used and whether unaffected files remain valid. Avoid an escalating chain of names such as final-final-new. A simple release number or dated identifier is usually easier to relate to the delivery message and manifest.

What to know

Handle the distribution consequence

Consider who received the earlier route and what action they need to take. Changing a source folder does not establish that downloaded copies have changed. Use the agreed project communication channel to announce the correction. Where production has already begun or contractual consequences exist, follow the responsible project process instead of treating the storage interface as an automatic recall system.

What to know

A fictional correction notice

Release 05 replaces only the print PDF from release 04 to correct a telephone number. Screen assets are unchanged. The client is asked to use the newly identified print file and confirm the relevant downstream recipient has the correction. The record preserves both releases privately. That precise instruction is more useful than sending a fresh link with no explanation and hoping everyone chooses the latest file.

What to know

Put the decision into practice

Keep a correction log naming the previous release, replacement release, affected files and notification status. This helps answer which version reached which stage of the client workflow. It does not establish that every downstream copy was replaced, so leave that uncertainty explicit when it affects the project.

Continue when useful

Next: Delivery manifest

List what the release contains, what it excludes and how the client should use it; a folder count is not a manifest.

Open Delivery manifest →

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. pCloud file transfer and organization — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29
  2. pCloud shared links — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29