Skip to content
DevMarket
Odoo ModulesWordPress PluginsWordPress ThemesShopify ThemesApp TemplatesScripts & UtilitiesBlogSell on DevMarket
Selling software

How to Ship Software Releases That Pass Marketplace Review

A release that fails review costs days. Prepare a clean archive, use clear version numbers, write a honest changelog, state compatibility and test on a fresh install so your release is approved the first time.

By DevMarket EditorialPublished: 4 min read
How to Ship Software Releases That Pass Marketplace Review
On this page

On a marketplace where people review releases before buyers can download them, a rejected release means lost days. Most rejections are not about bad code. They come from preventable details: a messy archive, a missing changelog, versions that do not match, or compatibility that was never tested. This guide shows how to prepare a release that passes the first time.

It is written for authors on DevMarket, where each release is checked by a person before it becomes available, but the same habits help on any platform.

What a review looks at

A release review is a quality and safety check, not a guarantee of your software. Reviewers look at:

  • whether the archive is intact and safe to unpack;
  • whether the version, changelog and compatibility information are present and consistent;
  • whether the release matches the description on the item page;
  • whether anything in it is unsafe or misleading.

Knowing this tells you what to prepare.

Package the archive cleanly

Your release is a single zip file. Make it tidy:

  1. Include only what buyers need: the code, documentation and licence. Leave out build folders, dependency folders you can install, caches, editor files and personal notes.
  2. Use a sensible folder structure with the name of the item at the top.
  3. Do not use unusual paths. Paths that climb out of the folder (using ..), absolute paths, links to files outside the archive and files with strange names are rejected, because they can be used to attack a buyer's machine.
  4. Keep the size reasonable. A very large archive for a small item raises questions.
  5. Open the zip yourself on a clean machine and check that it extracts without errors.
Three cards joined by arrows from left to right, the last one marked with a green tick
Package, describe, submit: a clean release moves through review without a second round.

Use clear version numbers

Pick a numbering scheme and keep to it. Dotted numbers such as 1.2.0 are easy to read. For Odoo modules, many authors prefix the Odoo series, as in 19.0.1.2.0. Increase the number with every release, and never upload two different archives under the same version. If you must replace a rejected upload, fix it and upload it again under the same number: a rejected release does not block you from trying again.

Write a changelog people can use

The changelog is read by buyers deciding whether to update and by reviewers checking the release. Say what changed in plain words:

  • Added: new features.
  • Changed: behaviour that works differently now.
  • Fixed: bugs, with what the symptom was.
  • Security: anything that fixes a security problem. Mark it as a security release.

"Bug fixes and improvements" tells nobody anything. Even one specific line per change is better.

State the platform versions you support

Choose the platform versions this release works with, and mean it. If you say it works with Odoo 17.0, 18.0 and 19.0, you should have tested all three. If you only tested one, say one. Buyers rely on this list, and a wrong claim leads to support requests, bad reviews and refunds.

Test before you submit

Create a fresh environment, install your release the way a buyer would, and run through the main features. Install it on each supported platform version. Check that upgrading from the previous release works, and that uninstalling or deactivating leaves the system healthy. Keep a short test script so that every release gets the same checks.

Make sure the description still matches

If the release adds or removes features, update the item description and screenshots too. Reviewers compare what you promise with what you ship. A page that describes features the archive does not contain is a common reason for a request to change.

Be open about what the software does

State if the software connects to external services, sends data anywhere or loads code from elsewhere, and describe what and why. Hidden tracking or hidden data collection is not allowed, and it destroys trust when found. Honest disclosure is simple and protects you.

A pre-submission checklist

ItemReady when
ArchiveOpens cleanly, no unsafe paths, no clutter
VersionNew, consistent, in the same style as before
ChangelogSpecific, with security fixes flagged
CompatibilityOnly versions you tested
TestFresh install, upgrade and uninstall checked
DescriptionMatches the release
DisclosureExternal connections described

If your release is sent back

Read the reviewer's note carefully, fix the points it lists, and upload again. Treat each note as a free quality check. If you are unsure what a note means, ask.

Next steps

Once your releases are in good shape, make sure the page that presents them is too: read how to write a product listing that sells, and think about how to price and license your software. To sell on DevMarket, start from the seller page.

Find the right software for the job

Every item on DevMarket has a human-reviewed release, an instant licence key and clear update and support terms.