In early July, Antigravity shipped several builds on the same day. A feature-leaning line like 2.1.4 and a stability-leaning line like 2.0.11 now advance in parallel. This is a welcome change, but it hands the solo user a new chore: you have to decide which line to ride, yourself.
The more you hand automated posting or scheduled batches to an agent, the heavier this call becomes. New features are attractive, but if behavior shifts with every update, a job that ran quietly overnight might be silently failing by morning. This article designs how to choose between the two lines and how to switch between them safely.
What it means for two build lines to run in parallel
Stable and feature lines diverge because their goals differ. The stable line leans toward "keep tomorrow's behavior the same as today's," taking in a narrow set of fixes. The feature line leans toward "try new capability sooner," pulling in changes aggressively. Neither is above the other; they simply suit different moments.
The trap is unconsciously mixing both on one machine. If a plan to try a feature by hand also updates the runtime your automation uses, operations pay the price of exploration. So the first thing to decide is "which work rides which line."
| Nature of the work | Recommended line | Why |
|---|---|---|
| Overnight batch, scheduled runs, auto-posting | Stable (2.0) | Consistent behavior comes first; fewer changes are better |
| Hands-on exploration, trying new features | Feature (2.1) | A human is present to notice failures on the spot |
| Final check before a production release | Stable (2.0) | You want to pass in a reproducible environment |
Pin the version and reconcile before startup
Deciding to "ride the stable line" means nothing if it drifts upward on its own. First, write down the version this project uses. Declare the pinned version in a single human-readable file, and at automation startup, reconcile it against what is actually installed. If they diverge, stop before starting.
// .antigravity-version.json — declare the build this project rides
{
"line": "stable",
"pinned": "2.0.11",
"allowPatchDrift": false
}#!/usr/bin/env bash
# preflight.sh — call at the top of automation; reconcile pinned vs actual
set -euo pipefail
PIN=$(grep '"pinned"' .antigravity-version.json | sed -E 's/.*: *"([^"]+)".*/\1/')
ACTUAL=$(antigravity --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [ "$PIN" != "$ACTUAL" ]; then
echo "⛔ Version mismatch: pinned=$PIN actual=$ACTUAL" >&2
echo " Aborting automation. If the switch was intended, update .antigravity-version.json." >&2
exit 1
fi
echo "✅ Version matches: running on $ACTUAL"The value of this preflight is turning "it went up without me knowing" into "it stopped and I noticed." For unattended operation, stopping loudly before it starts is far safer than leaking failures quietly.