​

Publish & Deploy

​

Sources

Docs: Propose Web App: Open an Admin Parable’s Publishing panel for Publish & Deploy. Choose the audience for that publication in Deployments. Publish & Deploy is the staff action that accepts approved Changes, creates one Version, and deploys that Version to the selected Workspace audience. The review decision and target audience are visible before approval. When a Workspace line publishes a Version, everyone reading that Parable hears it: a reader of the newest Version sees Updated to v1.84 when they are switched to it, and one reading an older Version is offered the new one at once. A reader of the newest Version switches when the new Version’s stored Plots can be served: at once, or after its first Refresh completes when the publish changed what they return (Reports). A save of a Versioned setting by someone with Publishing publishes a Version this way too, numbered by the release it asks for. Publish and Deploy remain separate actions. Publish moves reviewed Changes forward on one Parable line and creates a Version. Deploy changes which Workspaces receive an already published Version; it does not create another Version. Use Publish & Deploy only when both effects are intended. A Workspace publication makes a reviewed Version current on that Workspace line. Only the Admin surface can widen the audience by deploying to another Workspace. Changing the selection in Deployments prepares the audience for the next publication. That selection alone does not deploy a Version. Publishing a Workspace line from the Admin screen still uses that Workspace’s publishing permission and command status. Staff access does not replace the Workspace publication grant. The source Workspace already owns the Version and receives no Delivery. All Workspaces reaches the other Workspaces; a selected audience must also exclude the source Workspace.

​

Review the blast radius

Before confirming:

• identify the exact Parable and proposed version;
• verify the responsible and accountable people;
• inspect the target Workspaces;
• check required Proofs, compatibility, and recovery;
• confirm whether the action can be reversed; and
• do not rely on a Ponder response as the approval itself.

Delivery may complete at different times for different targets. Read each visible status and retry only the targets whose recovery action permits it. A newly delivered Parable can be read in Peeking before the Workspace pulls it. It uses the delivered definition and the Workspace’s existing Policy checks. Pull brings that delivery into the Workspace’s own change review; it is not a prerequisite for viewing the delivered app. A later Delivery is different: the Workspace’s readers keep its current Release, and cannot open the delivered one, until the Workspace Pulls the Delivery and Publishes it. The receiving Workspace’s administrators hold Primary on the delivered Parable, so they can pull the Delivery, publish it, and assign responsibilities to others. Other members can read it and comment. A later Delivery preserves unchanged upstream Pieces and the Workspace’s own changes. Pieces removed by the Workspace stay removed unless the review explicitly resolves a conflicting upstream change.