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 4
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 steps
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.