Publish a data app (api kind one-step publish)
Deprecated: submissions now go through the portal’s contract import wizard (backed by POST /data-apps/contract/assemble) or the three-step chain (workspace → builds → releases). Kept for the built-in console and existing tests; removal will be scheduled separately.
One-step publish sugar for api kind (declarative integration): internally an atomic chain of create identity → save Workspace → freeze Build → promote Release; submitting is publishing.
The version number is fixed by the publish action: default = patch+1 over the current largest Release (0.1.0 for the first); the submission need not and does not carry a version (identity.version is ignored on this path). To specify a version explicitly (expressing a major/minor bump), use the three-step chain’s POST /data-apps//releases. code kind (code packages) does not use this sugar: image builds are async, so “submit = published” does not hold — follow the three-step chain (PUT workspace → POST builds → poll until ready → POST releases).
The namespace is inferred from authentication: identity.app_name in
the manifest carries only the app name (no prefix of any kind), and
the app lands under the publisher’s own (user, app name) — the
package is author-uploaded text that could say anything; the only
proof of identity is which key you publish with. Same-named apps
across users coexist naturally, and there is no namespace
declaration slot to impersonate.
The app identity (app_id) is minted exactly once; renaming the user
or the app never changes it. External references are always the
two-part <namespace>/<app_name> form. Releases are immutable:
publishing again appends a new version, old versions are never
overwritten, and runs in flight or historical references pinned to
old versions are unaffected by a publish.
Two name gates precede publishing: the account must have a username
(without one the two-part reference is unreachable and nobody could
call the published app, 400); and the historical ownership of
(username, app name) must be yours — after a username changes
hands, app names used by the previous holder enter a freeze
(30 days from when the platform first observes the handover) and
cannot be reused within it (409), protecting stray external
references from takeover.