Versioning

[dorodere]

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.

[dorodere]

Had this thought:

• Biweekly main bumps its version respecting breaking changes, if any changes have been made.
• Then a branch named candidate snapshots main at that version bump.
• The snapshot on candidate is tested & reviewed.
• Update instructions are written including which database migrations to run, forming a PR which is submitted to the protected release branch.

Things to note:

• Unconditionally run 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)

[dorodere]

Migrations are to be named something along the lines of {last_version}-{number_of_migration_for_this_version}-{description}.sql.