Versions and Publishing
While an object is only yours, versions are noise. The moment a second person places it, every change you make lands in somebody else's part, and you need a way to say how big that change was. Publishing is how you get that, and it happens outside the editor, in the store wizard.
There is no publish step inside the smart object editor. It writes a draft, autosaved, and every placement of one of your local objects follows that latest draft. There are no version buttons, no release notes and no semver field on that screen; anything you have read that describes one is describing something that was never built.

Sharing without publishing
Two ways an object reaches another person.
Send the file. Export the object and hand over the file. The recipient drops it into their file manager and it becomes an object in their library. This is the whole sharing story for code objects.
Publish it to the store, which is public and reviewed. There is no unlisted or private tier: an approved listing is visible to everyone, and its page carries link-preview metadata so it can be posted anywhere.
If what you want is "a few colleagues, not the world", the file is the answer, with one condition attached. Importing a smart object needs the Maker plan, both for a .kpy and for a .kpycode. A colleague on the free plan who drops your file gets the upgrade panel rather than an object. Placing an object is free; accepting one as a file is not, so check what your colleagues are on before you decide the file is the channel.
The publish wizard
Publishing starts from the store rather than from the object, and it takes a document from your files. The header reads Publish a Smart Object over Share a Smart Object from your files so anyone can drop it into their own design., and a standing banner sets the expectation: Everything you publish goes through review before it appears in the catalog.
The steps are conditional, so the wizard is shorter than a screenshot of somebody else's publish suggests. Source, Details and Review are always there. Version appears only when this document already has a release out. Parameters and Presets appear only when the document exports parameters, and they arrive as a pair. A first publish of an object with no exported parameters is three steps: Source, Details, Review.
Parameters and presets
The Parameters step introduces itself as These come from the document itself. Set the range each one can be configured within, and say what it does. This is the only place a parameter gets a minimum, a maximum, a step and a description, and the bounds are what turn a number into a slider on the consumer's panel. Choosing the Parameters You Expose covers what to fill in and why.
The Presets step describes itself as Named combinations of values, so people can start from something that already works. Despite the No presets yet. They are optional. line inside it, it is a gate: an object with parameters cannot be submitted with an empty preset list. The wizard seeds one called Default from the document's own values, so the step arrives already answered, and renaming that seed to something a consumer recognises is a minute well spent. A listing whose first preset already prints is a listing people keep.
Which bump
The Version step exists only on a repeat publish, and you reach it from New version on the listing in My objects: the source picker marks an already-published document Already published and will not let you pick it again. It asks how big the change is, in the language a consumer needs rather than yours:
| Bump | What the wizard says |
|---|---|
| Patch | Fixes and small tweaks. Nothing anyone has to relearn. |
| Minor | New parameters, presets or geometry, and the old settings still work. |
| Major | Changes that break old configurations, like removing or renaming a parameter. |
Renaming a parameter is a major change, however small the edit felt. Someone's placement is holding a value for a name that no longer exists.
There is no version field anywhere in the wizard. A first publish is 1.0.0, fixed, and after that the number is computed from the bump you pick. The only thing you type on this step is What changed, shown on the listing next to this version, so people know whether to update. Write it for a stranger deciding whether to touch a working part. Wider magnet slots, and a new preset for 3 mm plates. is the shape.
Review, and afterwards
Submitting ends with Submitted. We will let you know once it is reviewed. A person reads it before it appears.
Your listings live under My objects, with a status on each: Draft, In review, Published, Rejected, plus the badge New version in review on a listing whose next release is queued. The page also carries Updated, Downloads, Rating and Version.
A new version in review never disturbs the version already out there. Approval promotes; a rejection leaves the published listing exactly as it was. You cannot break a live listing by submitting a bad update, only by publishing a good one badly.
Local versions exist only for code objects
An object built from features has no version history at all. Its placements follow the latest draft, always, and that is the design rather than a gap.
A code object does keep local versions, stamped from the version string in its meta block, written by the explicit save. Saving twice with the same string overwrites that version in place, and placements pinned to it change. Bump meta.version before saving a change to geometry, or the pin means nothing. Objects Made of Code has the detail.
Store releases are the opposite: once approved, a published version is fixed and cached, which is why pinning a store object is worth doing on a part that matters.
Nothing pushes a version onto a placement
Publishing does not update anybody. A placement pinned to a version stays there for ever, and one tracking the latest release picks up your work only when its source is next fetched, which for most people means the next time they open the file. There is no notification anywhere in the app.
The control that does pull one is on the consumer's side: Refresh to latest, a ↻ row under Version in the placement's timeline popover. It is offered on a store object while the pin is Latest or Draft, and always on an object from your own library. Somebody has to click it, and nothing tells them to.
So the release notes are not a formality. They are the only channel you have, and they are read after the fact by someone who has already noticed something moved. Versions and What Goes Wrong covers the same mechanism from the consumer's side.
When it fails
The wizard mostly refuses by leaving Next disabled rather than by printing anything, so a step that will not advance is a field you have not filled: a source, a name, a category, a description, bounds on a parameter, a preset. Only two refusals are ever spelled out:
Say a bit more — at least {{min}} characters.on Details, where the minimum is 50 characters and the counter beside the box tells you where you are.A slider needs a minimum and a maximum.on Parameters, which also fires on a missing or non-positive step.
Two things that are not error messages but stop people:
The Source step says You have nothing to publish here yet. Publishing takes a document from your files, so the object has to exist there first.
A flag reads Uses smart objects referenced internally — publish them and use their store version instead:. Your document places objects that only exist in your library, and nobody else can build it. Publish those first.
See also
- Choosing the Parameters You Expose: the bounds and descriptions the wizard asks for
- Objects Made of Code: local versions, and the save that overwrites one
- The Smart Object Editor: what the editor saves, and what it does not
- What a Smart Object Is: where objects come from, from the other end
