Migrating to v0.10.0

v0.10.0 carries no functional change over v0.9.3. It exists to version the runs-store schema 3 → 4 change correctly: that change shipped in v0.9.2 and v0.9.3 as a patch, which understates a persisted record-shape change (breaking, and therefore a minor bump pre-1.0 per VERSIONING.md). v0.10.0 is the canonical, properly marked home of the break. If you already run v0.9.2 or v0.9.3 your database is on schema 4 -- no further store change is needed; read on only if a module of yours pins sparkwing.

Runs-store schema 3 to 4Section anchor link

Schema 4 adds a sparkwing_meta table -- a singleton key/value store backing throttle stamps and other small operational state. The store applies the migration automatically and idempotently the first time a schema-4 binary opens the database; you never run a migration by hand, and existing rows are untouched.

The break is not the migration itself -- it is version skew. A sparkwing binary refuses to open a database recorded at a schema newer than the binary understands, naming both versions:

sparkwing: database is at schema version 4; this binary expects 3.
Upgrade sparkwing or restore the database to a matching version.

This bites a module that pins an older sparkwing and shares the same state database -- most commonly a .sparkwing/ jobs module whose go.mod still pins a schema-3 sparkwing (v0.9.1 or earlier). Once any schema-4 binary has opened the shared database, that pinned module's pre-commit / pre-push gate opens the same database, sees schema 4, and refuses -- freezing the consumer's commit gate even though nothing in its own code changed.

Upgrade stepsSection anchor link

If you have a module that pins sparkwing (a .sparkwing/ jobs module or any consumer importing github.com/sparkwing-dev/sparkwing), bump the pin to a schema-4 sparkwing:

Before -- .sparkwing/go.mod pins a schema-3 sparkwing:

require github.com/sparkwing-dev/sparkwing v0.9.1

After -- pin a schema-4 sparkwing and tidy:

require github.com/sparkwing-dev/sparkwing v0.10.0
cd .sparkwing
go mod tidy

Commit the go.mod / go.sum change. The gate then runs against a binary that speaks schema 4 and the refusal clears.

If you do not pin sparkwing in a separate module -- you only run the sparkwing CLI or controller -- there is nothing to do: the binary you upgrade to migrates the database on open.