Block versioning

Platform: Mobile (Archer Setup app)

Archer keeps a version history of every block's geometry. This prevents accidental edits from disrupting field work already underway, and gives you a clean way to change block mapping without losing the history of what was there before. You manage versions from the block's detail screen in the mobile app.

The three statuses

Every block version has one of three statuses. The status chip on each version shows the label exactly as below:

• Draft — in-progress. Not visible in the portal for use in jobs and work plans. Drafts are the only versions you can edit, so use a draft to capture or revise a boundary without affecting live work.
• Release — the live, operational version. (Internally this is the "released" state; the chip reads Release.) Only released versions are visible in the portal for jobs and work plans.
• Deprecated — an older released version that has been superseded by a newer release.

At any time, a block normally has exactly one released version (the live one) plus zero or more drafts and deprecated versions in its history. The newest version also carries a Latest badge.

When a new version is created

The first time a block is captured it gets a starting version (version 1), and that version starts out released — so a newly captured block is immediately usable in the portal. Only Draft versions can be edited, so once a version has been released you can no longer edit its geometry directly — Archer protects the live boundary. To change a released block you must create a New Draft first (see below), edit that draft, then release it.

Attribute edits like planting settings (plant spacing, plants per bay) and per-version notes don't create a new version.

Opening the version history

1. Open the block from its vineyard to reach the block detail screen.

2. Scroll to the Version History card. Each version is listed with its number, status chip (Draft / Release / Deprecated), the Latest badge on the newest one, and the last-updated date.

   📷 Screenshot: Block detail screen Version History card showing versions with Release / Draft / Deprecated status chips and a Latest badge.

3. Tap a version to select it (a tick appears on the selected version). Each version also has a three-dot (⋮) overflow menu with the actions for that version.

   📷 Screenshot: Version overflow (three-dot) menu open, showing Compare with other versions, Add/Edit Notes, Release Version, New Draft, and Delete Draft.

Editing a draft's geometry

You can only edit geometry on a Draft version.

1. In Version History, select the draft you want to edit.
2. Tap the edit (pencil) icon in the top-right of the screen (tooltip: Edit Geometry). This opens the block in the mapping wizard.
3. Make your changes and save. The geometry is saved back to that draft.

If you tap Edit Geometry on a released or deprecated version, the app shows: "Only Draft block versions can be edited. Create a new Draft version first."

Creating a new draft

To change a block that's already released, make a new draft to work in.

1. In Version History, open the overflow menu on the latest version (the New Draft action only appears on the latest version).
2. Choose New Draft. (If the latest version is itself a draft, this option reads Duplicate Draft.) Archer creates a new draft copied from the latest version and selects it.
3. Edit the new draft's geometry as above, then release it when you're ready.

Releasing a version

Releasing makes a version the live one that the portal uses for jobs and work plans. You can release a draft or re-release a deprecated version.

1. In Version History, open the overflow menu on the version you want to release.

2. Choose Release Version.

3. Confirm in the dialog. If a version is already released, the dialog warns that releasing this one will deprecate the currently released version. Tap Release.

   📷 Screenshot: "Release Version X?" confirmation dialog with a Release button.

When you release, the previously released version (if there was one) becomes Deprecated.

Rolling back to a previous version

If a release introduced a problem, you can roll back to an earlier version.

1. In Version History, find the older (now Deprecated) version you want to return to.
2. Open its overflow menu and choose Release Version.
3. Confirm. That version becomes the released one, and the version that was current becomes Deprecated.

Rolling back changes which version is released — it does not create a new copy. If you then need to tweak that boundary, create a New Draft from it first, since released versions can't be edited directly.

Comparing versions

When a block has more than one version you can compare any two side by side.

1. In Version History, open the overflow menu on a version and choose Compare with other versions.

2. Pick the version to compare it against. (Use the swap icon in the top bar to flip which version is "old" and which is "new".)

3. The comparison screen shows the two boundaries drawn over each other on a map, a colour Legend, a Summary of how many rows changed, and a Changed Rows list describing each difference.

   📷 Screenshot: Version comparison screen with the overlaid boundaries, colour legend, and changed-rows summary.

The legend explains the colours and line styles:

• Unchanged — grey
• Position changed — orange
• Breaks changed — red
• Both changed — purple
• Added — green
• Removed — pink
• Dashed lines = the old version, solid lines = the new version.

Per-version notes

Each version can carry its own note — handy for recording why a draft was created or what a release changed.

1. In Version History, open the overflow menu on a version.
2. Choose Add Notes (or Edit Notes if a note already exists).
3. Type your note and tap Save. The note appears under that version in the history.

Tips

• Don't leave drafts lying around. If a draft exists, field staff may assume it's the intended new boundary. Either release it or delete it. To remove a stray draft, open its overflow menu and choose Delete Draft (only available on draft versions; this permanently deletes the draft and its local edits and can't be undone).
• Coordinate releases with operations. If a crew is actively working against a released version, releasing a new one mid-run can surprise them. Best to release outside of active work windows.
• Deprecated versions are kept for history, not for work. They help you answer "what did the block look like when we worked it last month?"