Closed dorodere closed 1 year ago
Had this thought:
main
bumps its version respecting breaking changes, if any changes have been made.candidate
snapshots main
at that version bump.candidate
is tested & reviewed.release
branch.Things to note:
cargo build --frozen
on any version bump and refuse to accept the commit if that fails. Frozen builds are nice and important.We probably need some kind of upgrade script that basically runs this on an instance (pseudocode):
i_can_has_version() := $(cargo metadata --format-version=1 --no-deps)["packages"][0]["version"]
before_version = i_can_has_version()
$(git pull)
$(cargo build --release)
after_version = i_can_has_version()
required_migration(filename) := (before_version ..= after_version).contains(filename.extract_version())
migrations = lsdir("$TOPLEVEL/scripts/migrations").filter(required_migration)
$("$TOPLEVEL/scripts/migrate.py" $DATABASE migrations)
Migrations are to be named something along the lines of {last_version}-{number_of_migration_for_this_version}-{description}.sql
.
The upcoming database migrations just count up per every migration, but it's currently impossible to tell which migrations to apply when the application hasn't been updated for X days.
We need to find some versioning solution which allows both consistent + stable results, while making clear what and how to upgrade.