Shipping a Release

9 views Markdown

Ship a new version of a published product: what it carries, how it is reviewed, and how buyers hear about it.

Overview

A listing is reviewed once. A product keeps changing. Every version after the first travels as a release: a number, a changelog and the whole package. Each one is handed to the moderators and approved on its own.

Approval is what publishes. Until a moderator says yes, nothing about the live listing moves and no installation is told anything. After it, the listing states the new version and the catalogue hands out the new package.

Prerequisites

A published listing Only a live product has a next version. A draft is still its first submission, and a refused or retired listing has nothing to update.
A number above the live one Compared segment by segment, not as text, so 1.10.0 is above 1.9.0. A number already used is refused as well.
The whole product The package is a complete build, never a patch. It replaces the directory on the customer's side.
A changelog you can write in lines Up to 40 lines, each up to 300 characters, each one typed.

Structure

The release editor has the same shape as the product editor. Sections with a readiness meter, and a submit action that counts them again on the server.

SectionWhat completes it
DetailsThe product, the version, and at least one changelog line
PackageThe full build for that version
LicensingInherited from the listing, so it is already complete unless you change it. Asked whatever the product costs
ReviewThe confirmations, as on a listing

Changelog lines carry a kind, and every surface that shows a changelog groups them by it: features, improvements, security, fixes, changed. One free paragraph reads as prose nobody scans; a typed list says at a glance whether a version carries a security fix.

Walkthrough

Prepare the version

  1. Open Releases in the developer portal and start a new one. Pick the product; the picker offers published listings only.
  2. Enter the version number. The live one is shown next to the field, so "must be higher" is a fact on the page.
  3. Write the changelog line by line and give each line its kind.
  4. Upload the package for that version, and update the compatibility range if this build changed it.

Check the licence declaration

  1. The version carries the declaration of its listing, free or paid. Leave it alone and the section is already done.
  2. Change it when the address or the credentials moved, then test it here. Wiring and fields: Licensing a Marketplace Product.
  3. What you change is parked on this version. It reaches the listing only when a moderator approves, so the key and the build that carries it travel together.

Submit and wait

  1. Submit the release. It moves to Submitted, the package freezes and the editor becomes read only.
  2. Withdraw is open while it is only submitted. Once a moderator picks it up the state becomes In review and it closes.
  3. A refusal carries a reason and reaches your account as a notice. Fix it and submit again.

After approval

  1. The listing starts stating this version, and hands out the compiled package built from yours.
  2. Installations that hold the product ask once a day and are offered the update.
  3. Nothing installs itself. The operator reads the changelog and decides.

Reference

What approval moves from the release onto the listing, at the same instant.

VersionThe listing starts stating this number, and it becomes the one clients compare against.
PackageThe download and the update feed both start serving this build.
Compatibility rangeMoves only when this version set one. A listing never advertises a requirement its own package lacks.
Licence declarationOnly when this version parked one. This is the single way a published listing's verified declaration changes.

An update is offered only when three things hold at once. Any one failing answers "nothing published" rather than an error, because the buyer did nothing wrong.

GateWhy
The listing is liveA retired or refused product has nothing to push to anyone.
The developer account is activeA studio switched off here does not ship code into customer panels.
The customer account behind it is activeYou are a customer here too, and a closed account no longer delivers files.

Example

An installed marketplace product carries a manifest naming the listing it came from. A directory name is your own choice and two studios may pick the same one, so identity travels as the listing id.

coremio/modules/Addons/SamplePro/manifest.json 
{"type": "marketplace", "id": 42, "version": "1.2.0", "last_updated": "2026-08-06"}

The installation asks about that id and reads back what is published for it.

the update feed, as the customer's panel calls it 
GET /api/v1/marketplace/releases/42?version=1.2.0&lang=en

Pitfalls

A patch is not a release

The package replaces the product directory. Ship only the changed files and everything you left out disappears from the customer's copy.

A submitted release is frozen

The package cannot be replaced while a decision is pending. Withdraw it while it is still only submitted, or wait for the answer.

Your schema changes have to apply themselves

Nothing in the update path runs a script of yours. Migrations run from a normal code path, safely, on every request.

Was this helpful?

Thanks for your feedback!

Still Need Help?

Our support team is here around the clock for anything you can't find above.

Contact Us Open a Ticket

We use cookies to keep you signed in, remember your language and currency, and improve the site. Cookie Policy