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.
DEBy DevMarket Editorial·Published: ·4 min read
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:
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.
Use a sensible folder structure with the name of the item at the top.
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.
Keep the size reasonable. A very large archive for a small item raises questions.
Open the zip yourself on a clean machine and check that it extracts without errors.
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
Item
Ready when
Archive
Opens cleanly, no unsafe paths, no clutter
Version
New, consistent, in the same style as before
Changelog
Specific, with security fixes flagged
Compatibility
Only versions you tested
Test
Fresh install, upgrade and uninstall checked
Description
Matches the release
Disclosure
External 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.
You can sell a WordPress plugin, but you cannot take away the freedoms the GPL gives buyers. Learn free-plus-paid or premium, licence keys, updates, pricing, quality checks and where to sell.
Learn how to sell digital products online: what counts as one, where to sell, how to price and licence it, protect downloads, handle tax and refunds, and launch with a simple checklist.
A listing is your salesperson. Learn how to structure the opening, screenshots, features, compatibility, FAQ and changelog of a software listing, and how a demo or tour builds trust.
·5 min read
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.