One release, four useful outputs
Select the finished delivery files, enter the version and buyer-facing changes, then generate a manifest JSON, buyer update TXT, internal changelog TXT, and archive index HTML. The files stay in your browser while the tool reads their names, sizes, and contents needed for SHA-256 checksums.
The four outputs serve different moments in the same workflow: approving the release, explaining it to buyers, preserving production notes, and reopening the archive later.
Manifest JSON and buyer update TXT
The manifest records the exact filenames, byte sizes, SHA-256 checksums, version, supported platforms, license, and AI-use disclosure. It is the machine-readable evidence of what belonged to the approved package.
The buyer update turns the same release into plain language: what changed, whether the customer needs to download again, and any action required. Review compatibility and support claims before sending it.
Internal changelog and archive index
The internal changelog keeps production details out of the buyer message while preserving what changed and why. The archive index is a human-readable HTML page that ties the release records together when you revisit the package months later.
Keep all four outputs beside the approved delivery archive. They describe the product release and should not contain buyer names, email addresses, payment details, or private download links.
What the tool does not decide
Release & Update Manager organizes the facts you provide; it does not verify marketplace rules, software compatibility, licensing rights, or the accuracy of product claims. You remain responsible for testing the delivered files and reviewing every generated record.
Examples included with the tool are fictional workflow demonstrations. Replace them with facts from your own release rather than copying compatibility or support language unchanged.