Make compatibility explicit.

Schema version 1 binds an application to stable repository, release, asset and publisher identities. A filename is a suggestion, never compatibility evidence.

What belongs in a manifest

• Application identity, publisher, category, summary, approved license, and free-app declarations.
• Exact GitHub repository ID, release ID, tag, semantic version, source commit and channel.
• Local, cloud-connected, or hybrid execution; offline capability; required and optional services with cost disclosures.
• Data egress, retention, telemetry, filesystem and credential access, network domains, privileges and background services.
• Models, source and licenses, checksums, unsafe loading flags and executable downloads.
• Updater coordination and data compatibility or backup requirements for rollback.
• One explicit mapping per asset with OS, validated processor set, format, adapter and minimum requirements.

Generate, validate, submit

The publisher workspace generates a manifest from your inputs and selected release assets. Review the complete JSON before saving or submitting. The server validates the same schema and independently checks ownership and upstream identities.

Asset size and final digest are derived by verification, after any signing or notarization. Publishers do not need to calculate trusted acquisition digests manually.

Multiple architectures and formats

Use separate asset mappings for x64 and ARM64 installers. A macOS universal package declares both architectures and requires independent binary inspection. MSI and NSIS can coexist for Windows when each has applicable verification. Linux DEB and RPM require explicit distribution compatibility.

Changed assets require new evidence

Replacing bytes under the same filename does not preserve acceptance. Missing or ambiguous mapping remains incomplete. Tags, source commits, release IDs, asset IDs and digests must agree.