talexander/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Releases Activity

garage_0_9: mark eol

Browse Source
This commit is contained in:
Adam C. Stephens 2025-06-23 17:39:58 -04:00
parent 8a77cc3db4
commit 45c0608ace
No known key found for this signature in database
3 changed files with 5 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
nixos/modules/services/web-servers/garage.md
View File

@ -21,20 +21,14 @@ Garage has two types of upgrades: patch-level upgrades and minor/major version u
In all cases, you should read the changelog and ideally test the upgrade on a staging cluster.
Checking the health of your cluster can be achieved using `garage-manage repair`.
:::
::: {.warning}
Until 1.0 is released, patch-level upgrades are considered as minor version upgrades.
Minor version upgrades are considered as major version upgrades.
i.e. 0.6 to 0.7 is a major version upgrade.
:::
- **Straightforward upgrades (patch-level upgrades).**
Upgrades must be performed one by one, i.e. for each node, stop it, upgrade it : change [stateVersion](#opt-system.stateVersion) or [services.garage.package](#opt-services.garage.package), restart it if it was not already by switching.
- **Multiple version upgrades.**
Garage do not provide any guarantee on moving more than one major-version forward.
E.g., if you're on `0.7`, you cannot upgrade to `0.9`.
You need to upgrade to `0.8` first.
E.g., if you're on `0.9`, you cannot upgrade to `2.0`.
You need to upgrade to `1.2` first.
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.
@ -67,8 +61,8 @@ 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 `v0.8.0`
should be available in `nixpkgs` as `pkgs.garage_0_8_0`).
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

1
pkgs/tools/filesystems/garage/default.nix
View File

@ -116,6 +116,7 @@ rec {
hash = "sha256-2ZaxenwaVGYYUjUJaGgnGpZNQprQV9+Jns2sXM6cowk=";
cargoHash = "sha256-ittesFz1GUGipQecsmMA+GEaVoUY+C9DtEvsO0HFNCc=";
cargoPatches = [ ./update-time.patch ];
eol = true;
};
garage_1_2_0 = generic {

1
pkgs/top-level/all-packages.nix
View File

@ -3026,7 +3026,6 @@ with pkgs;
inherit (callPackages ../tools/filesystems/garage { })
garage
garage_0_9
garage_0_8_7
garage_0_9_4
garage_1_2_0