As long as [stateVersion](#opt-system.stateVersion) is declared properly,
    this is enforced automatically. The module will issue a warning to remind the user to upgrade to latest
    Garage *after* that deploy.

## Advanced upgrades (minor/major version upgrades) {#module-services-garage-advanced-upgrades}

Here are some baseline instructions to handle advanced upgrades in Garage, when in doubt, please refer to upstream instructions.

  - Disable API and web access to Garage.
  - Perform `garage-manage repair --all-nodes --yes tables` and `garage-manage repair --all-nodes --yes blocks`.
  - Verify the resulting logs and check that data is synced properly between all nodes.
    If you have time, do additional checks (`scrub`, `block_refs`, etc.).
  - Check if queues are empty by `garage-manage stats` or through monitoring tools.
  - Run `systemctl stop garage` to stop the actual Garage version.
  - Backup the metadata folder of ALL your nodes, e.g. for a metadata directory (the default one) in `/var/lib/garage/meta`,
    you can run `pushd /var/lib/garage; tar -acf meta-v0.7.tar.zst meta/; popd`.
  - Run the offline migration: `nix-shell -p garage_1 --run "garage offline-repair --yes"`, this can take some time depending on how many objects are stored in your cluster.
  - Bump Garage version in your NixOS configuration, either by changing [stateVersion](#opt-system.stateVersion) or bumping [services.garage.package](#opt-services.garage.package), this should restart Garage automatically.
  - Perform `garage-manage repair --all-nodes --yes tables` and `garage-manage repair --all-nodes --yes blocks`.
  - Wait for a full table sync to run.

Your upgraded cluster should be in a working state, re-enable API and web access.

## Maintainer information {#module-services-garage-maintainer-info}

As stated in the previous paragraph, we must provide a clean upgrade-path for Garage
since it cannot move more than one major version forward on a single upgrade. This chapter
adds some notes how Garage updates should be rolled out in the future.
This is inspired from how Nextcloud does it.

While patch-level updates are no problem and can be done directly in the
package-expression (and should be backported to supported stable branches after that),
major-releases should be added in a new attribute (e.g. Garage `v3.0.0`
should be available in `nixpkgs` as `pkgs.garage_3`).
To provide simple upgrade paths it's generally useful to backport those as well to stable
branches. As long as the package-default isn't altered, this won't break existing setups.
After that, the versioning-warning in the `garage`-module should be
updated to make sure that the
[package](#opt-services.garage.package)-option selects the latest version
on fresh setups.

If major-releases will be abandoned by upstream, we should check first if those are needed
in NixOS for a safe upgrade-path before removing those. In that case we should keep those
packages, but mark them as insecure in an expression like this (in
`<nixpkgs/pkgs/tools/filesystem/garage/default.nix>`):
```nix
# ...
{
  garage_1_2_0 = generic {
    version = "1.2.0";
    sha256 = "0000000000000000000000000000000000000000000000000000";
    eol = true;
  };
}
```

Ideally we should make sure that it's possible to jump two NixOS versions forward:
i.e. the warnings and the logic in the module should guard a user to upgrade from a
Garage on e.g. 22.11 to a Garage on 23.11.