Canonical update flow
BUMP IT
BUMP IT is the release move that keeps one app identity alive while the underlying artifact changes. It is how Vibecodr avoids turning every update into a new listing.
Release model for shipping the next version on the same canonical public app.
Implementation focus
Use this model whenever you want to update a live app, preserve backlinks and embeds, and keep older cuts exact for rollback or pinned references.
Expected outcomes
- Advance the live Drop without fragmenting the public app identity.
- Keep exact cuts available for rollback, embeds, and documentation references.
- Know when to publish as a new app instead of updating the existing one.
What BUMP IT is
BUMP IT is how you ship the next version of an app that already has a public page. It publishes a new version, moves the live app to that version, and keeps the older cuts around so you can pin or roll back later.
What stays continuous
- Builds a new artifact from the current draft.
- Moves the app's live Drop to that latest artifact.
- Keeps the same player page and app identity.
- Preserves every prior cut for revert and pinned embeds.
Why creators use it
- Your public page keeps its identity instead of splitting into duplicate listings.
- Existing followers, comments, and embeds can stay attached to the same app.
- Older cuts remain available when you need a pinned snapshot or a rollback.
- You can keep shipping one evolving app without losing its social continuity.
Canonical app identity
Vibecodr treats an app as one public thing that can keep evolving over time. BUMP IT exists so you can improve that app without turning every version into a separate public listing.
BUMP IT lifecycle
Canonical app post
-> live Drop points at latest artifact
-> BUMP IT creates a new artifact
-> live Drop updates to the new artifact
-> older cuts remain available for exact references while retained and allowedThe result: people keep seeing one app, while the version history stays clear underneath it.
When to use BUMP IT vs Publish As New App
Use BUMP IT when
- You are shipping the next version of the same app.
- The player page, follows, and discussion should stay continuous.
- You want existing live embeds to follow the latest version.
- You want rollback history and pinned cuts to stay attached to that same app.
Publish As New App when
- The work is intentionally a separate product or concept.
- You want a new public listing and a new lineage.
- The title, positioning, and audience meaningfully diverge.
- You do not want to inherit the existing app's social identity.
How to BUMP IT
- Open the live app in Studio from Player > Manage > Open in Studio, from Settings > Versions, or from your launchpad.
- Edit the draft until the new version is ready in preview.
- Choose BUMP IT to publish the new artifact onto the same app page.
- If you need to share a fixed snapshot later, use the Versions tab to copy a pinned cut.
Private and unlisted apps can be bumped too. The version changes, but the existing visibility rules stay exactly where you left them.
Cuts, embeds, and rollback
BUMP IT is deeply tied to cuts. Every bump creates a new cut, live embeds follow the current Drop, pinned embeds keep pointing at an exact artifact, and reverting creates a fresh append-only cut that matches an older version.
Live embed
Follows the app's latest published version after each BUMP IT.
Pinned embed
Stays fixed to one artifact even if the app keeps moving forward.
Revert
Creates a new cut that matches an older one instead of deleting history.
Canonical update flow
BUMP IT moves the live Drop for an existing app to a newer artifact while preserving the public app identity. It is the mechanism that lets a project evolve without losing backlinks, embeds, comments, remixes, or discovery continuity.
Older cuts remain exact references. The live route advances, but pinned or historical references can still point at the specific artifact they were created for.
- Use BUMP IT when the viewer should understand the release as the same app, improved.
- Publish a new app when the concept, audience, or public identity should split.
- Keep release notes and metadata aligned with what changed for viewers.
Rollback and reference behavior
The update model depends on immutable artifacts. Because each cut is preserved, the platform can reason about rollback, exact embeds, and historical references without pretending the old code was rewritten.
This is why publication is stricter than local preview: a public release becomes part of the app's lineage and social graph.
- The current Drop is the live app pointer.
- Artifacts are exact release records.
- Embeds and docs can choose live behavior or exact-cut behavior depending on the contract.
Example and read next
Example: you fixed a bug in an existing public app and want embeds, backlinks, comments, and discovery history to stay attached. Use BUMP IT so the live Drop advances without fragmenting the app identity.
Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.
- Read next: Source & Versions
- Read next: Studio
- Read next: VibeComposer
- Read next: How-To Guides