Release Process
Versioning
StoreIT uses semantic versioning (major.minor.patch). The version is defined once in the workspace root:
# Cargo.toml
[workspace.package]
version = "0.1.0"
All crates inherit this version via version.workspace = true.
Schema version is independent — tracked in the _meta table as an integer (currently 1). It only increments when the database schema changes. Defined as SqliteDb::EXPECTED_SCHEMA_VERSION in crates/storeit-db-sqlite/src/lib.rs.
Creating a Release
- Update version in root
Cargo.toml - Commit:
git commit -m "Bump version to 0.2.0" - Tag:
git tag v0.2.0 - Push:
git push origin main v0.2.0 - The release workflow builds all binaries and creates a GitHub Release with auto-generated release notes
Release Artifacts
Each release includes:
| Asset | Description |
|---|---|
storeit-server-linux-x86_64 | Linux x86_64 (glibc) |
storeit-server-linux-x86_64-musl | Linux x86_64 (static, musl) |
storeit-server-linux-aarch64 | Linux ARM64 (glibc) |
storeit-server-linux-aarch64-musl | Linux ARM64 (static, musl) |
storeit-server-darwin-aarch64 | macOS Apple Silicon |
storeit-server-darwin-x86_64 | macOS Intel |
storeit-server-windows-x86_64.exe | Windows |
storeit-ctl | Python management tool |
SHA256SUMS | Checksums for all files |
How Users Upgrade
Users run storeit-ctl upgrade which:
- Backs up data via the running server’s API
- Downloads the new binary from GitHub Releases
- Stops the server, imports data with the new binary, restarts
- Rolls back automatically on failure
See the migration system for the technical details.
Schema Version Changes
When adding a new migration that changes the DB schema:
- Increment
SqliteDb::EXPECTED_SCHEMA_VERSION - Add the sqlx migration file in
crates/storeit-db-sqlite/migrations/ - Add a transform arm in
interchange::transform_data()for the version transition - Run
make prepareto update the sqlx offline cache