Versions

A version is a frozen point in the application's history.

Every build becomes one#

Automatically. You do not save versions and you cannot forget to.

This is not a convenience. People do not save their own work, so the version that mattered is always the one nobody thought to save, and it is gone by the time they know they wanted it. Here nobody can lose a build by forgetting to press something.

A version is recorded whether the run succeeded, failed or was stopped. Half-finished work somebody wants to go back to is exactly what gets lost otherwise.

They are named after what was asked for#

Add a stage filter, not Version 7. That is what somebody searches for six weeks later.

Naming one yourself#

Press Name this version on a version in the Versions tab. Give it a name and, optionally, a note about what changed.

This is how you mark the build you will want to find again — First release, What the board saw, Before the pricing change. A named version stops being shown as one of the platform's automatic entries, so the list becomes the small number of points you actually care about.

Comparing two#

Before deploying, the dialog shows what changed between the version currently running in that environment and the one about to replace it. That is the question people actually ask before shipping — not what is in this version but what is different about it.

What a version costs#

Almost nothing. Storage is incremental, so fifty versions of an application cost about as much as one. There is no reason to delete them and no housekeeping to do.

Deploying twice with nothing changed#

Returns the version that already exists rather than creating a near-identical one. A history of eleven identical builds helps nobody find the one they meant.

Next#

• Environments — what preview, test and live are.
• Deploying — putting a version into one of them.
• Going back — restoring an earlier one.