Uploading versions
Publish a release so entitled customers can download it.
A version is one release of a product: an archive, a version number, and a release date. Customers download versions, not products.
Fields#
| Field | Notes |
|---|---|
| Product | Which product this release belongs to. |
| Version | A semantic version such as 1.4.2. Sorting and update checks rely on this being well formed. |
| File | The release archive. |
| File hash | A SHA-256 hash computed on upload. Customers can verify the download they received is the file you published. |
| Released at | The release date. This is compared against a subscription’s update expiry, so it is what actually decides entitlement. |
| Changelog | Optional notes shown to customers alongside the download. |
Where files are stored#
On a private disk — by default storage/app/plugins/ — which is never web-accessible. There is no URL that serves a release archive directly. Every download goes through a controller that checks entitlement first and then streams the file.
That means a customer cannot share a download link that works for anyone else, and a search engine cannot index your releases.
Release dates matter#
Do not back-date a release to before it existed. A customer whose update window closed in March is entitled to anything released before March; back-dating a June release to February hands it to people who have not paid for it.
Notifying customers#
Publishing a new version can notify subscribers of that product by email. Customers past their update window are not notified, since they could not download it anyway.
Superseding a release#
Upload a new version rather than replacing the file on an existing one. Customers who already downloaded the old build keep a record of exactly what they got, and the file hash stays meaningful.