nordic-dev.net/nixpkgs
nordic-dev.net/nixpkgs
2
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-12-04 21:03:15 +00:00
Code Issues Packages Projects Releases Wiki Activity
c93cfbfdad
nixpkgs/pkgs/servers/nextcloud/default.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

60 lines
1.8 KiB
Nix
Raw Normal View History

treewide: with stdenv.lib; in meta -> with lib; Part of: https://github.com/NixOS/nixpkgs/issues/108938 meta = with stdenv.lib; is a widely used pattern. We want to slowly remove the `stdenv.lib` indirection and encourage people to use `lib` directly. Thus let’s start with the meta field. This used a rewriting script to mostly automatically replace all occurances of this pattern, and add the `lib` argument to the package header if it doesn’t exist yet. The script in its current form is available at https://cs.tvl.fyi/depot@2f807d7f141068d2d60676a89213eaa5353ca6e0/-/blob/users/Profpatsch/nixpkgs-rewriter/default.nix
2021-01-11 07:54:33 +00:00
{ lib, stdenv, fetchurl, nixosTests }:
nextcloud: init at 10.0.0
2016-09-21 15:55:38 +00:00
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
let
nextcloud: 19.0.4 -> 19.0.6, 20.0.1 -> 20.0.3, mark v19 as insecure ChangeLogs: * https://nextcloud.com/changelog/#20-0-3 * https://nextcloud.com/changelog/#19-0-6 For Nextcloud 20, security advisories for CVE-2020-8259[1] & CVE-2020-8152[2] were published. The only way to fix those is to upgrade to v20, although v19 and v18 are supported, the issue won't be fixed there[3]. Even though both CVEs are only related to the encryption module[4] which is turned off by default, I decided to add a vulnerability note to `nextcloud19` since CVE-2020-8259's is rated as "High" by NIST (in contrast to Nextcloud which rates it as "Low"). If one is not affected by the issue, `nextcloud19` can still be used by declaring `permittedInsecurePackages`[5]. [1] https://nvd.nist.gov/vuln/detail/CVE-2020-8259, https://nextcloud.com/security/advisory/?id=NC-SA-2020-041 [2] https://nvd.nist.gov/vuln/detail/CVE-2020-8152, https://nextcloud.com/security/advisory/?id=NC-SA-2020-040 [3] https://help.nextcloud.com/t/fixes-for-cve-2020-8259-cve-2020-8152-in-nextcloud-18-19/98289 [4] https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_configuration.html [5] https://nixos.org/manual/nixpkgs/stable/#sec-allow-insecure Closes #106212
2020-12-10 19:57:42 +00:00
generic = {
version, sha256,
eol ? false, extraVulnerabilities ? []
}: stdenv.mkDerivation rec {
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
pname = "nextcloud";
inherit version;
nextcloud: init at 10.0.0
2016-09-21 15:55:38 +00:00
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
src = fetchurl {
url = "https://download.nextcloud.com/server/releases/${pname}-${version}.tar.bz2";
inherit sha256;
};
nextcloud*: add `passthru.tests` to reference VM-tests
2020-04-15 20:14:04 +00:00
passthru.tests = nixosTests.nextcloud;
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
installPhase = ''
nextcloud: add preInstall and postInstall hook calls
2021-05-21 08:31:38 +00:00
runHook preInstall
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
mkdir -p $out/
cp -R . $out/
nextcloud: add preInstall and postInstall hook calls
2021-05-21 08:31:38 +00:00
runHook postInstall
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
'';
nextcloud: init at 10.0.0
2016-09-21 15:55:38 +00:00
treewide: with stdenv.lib; in meta -> with lib; Part of: https://github.com/NixOS/nixpkgs/issues/108938 meta = with stdenv.lib; is a widely used pattern. We want to slowly remove the `stdenv.lib` indirection and encourage people to use `lib` directly. Thus let’s start with the meta field. This used a rewriting script to mostly automatically replace all occurances of this pattern, and add the `lib` argument to the package header if it doesn’t exist yet. The script in its current form is available at https://cs.tvl.fyi/depot@2f807d7f141068d2d60676a89213eaa5353ca6e0/-/blob/users/Profpatsch/nixpkgs-rewriter/default.nix
2021-01-11 07:54:33 +00:00
meta = with lib; {
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
description = "Sharing solution for files, calendars, contacts and more";
treewide: Per RFC45, remove all unquoted URLs
2020-04-01 01:11:51 +00:00
homepage = "https://nextcloud.com";
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
maintainers = with maintainers; [ schneefux bachp globin fpletz ma27 ];
license = licenses.agpl3Plus;
platforms = with platforms; unix;
nextcloud: 19.0.4 -> 19.0.6, 20.0.1 -> 20.0.3, mark v19 as insecure ChangeLogs: * https://nextcloud.com/changelog/#20-0-3 * https://nextcloud.com/changelog/#19-0-6 For Nextcloud 20, security advisories for CVE-2020-8259[1] & CVE-2020-8152[2] were published. The only way to fix those is to upgrade to v20, although v19 and v18 are supported, the issue won't be fixed there[3]. Even though both CVEs are only related to the encryption module[4] which is turned off by default, I decided to add a vulnerability note to `nextcloud19` since CVE-2020-8259's is rated as "High" by NIST (in contrast to Nextcloud which rates it as "Low"). If one is not affected by the issue, `nextcloud19` can still be used by declaring `permittedInsecurePackages`[5]. [1] https://nvd.nist.gov/vuln/detail/CVE-2020-8259, https://nextcloud.com/security/advisory/?id=NC-SA-2020-041 [2] https://nvd.nist.gov/vuln/detail/CVE-2020-8152, https://nextcloud.com/security/advisory/?id=NC-SA-2020-040 [3] https://help.nextcloud.com/t/fixes-for-cve-2020-8259-cve-2020-8152-in-nextcloud-18-19/98289 [4] https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_configuration.html [5] https://nixos.org/manual/nixpkgs/stable/#sec-allow-insecure Closes #106212
2020-12-10 19:57:42 +00:00
knownVulnerabilities = extraVulnerabilities
++ (optional eol "Nextcloud version ${version} is EOL");
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 It's impossible to move two major-versions forward when upgrading Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16) and trying to upgrade to 20.03 (using Nextcloud 18 by default). This patch implements the measurements discussed in #82056 and #82353 to improve the update process and to circumvent similar issues in the future: * `pkgs.nextcloud` has been removed in favor of versioned attributes (currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that approach we can safely backport major-releases in the future to simplify those upgrade-paths and we can select one of the major-releases as default depending on the configuration (helpful to decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be used on 20.03 and `master` atm). * If `system.stateVersion` is older than `20.03`, `nextcloud17` will be used (which is one major-release behind v16 from 19.09). When using a package older than the latest major-release available (currently v18), the evaluation will cause a warning which describes the issue and suggests next steps. To make those package-selections easier, a new option to define the package to be used for the service (namely `services.nextcloud.package`) was introduced. * If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to provide more recent Nextcloud versions on older NixOS-releases), an evaluation error will be thrown by default: this is to make sure that `services.nextcloud.package` doesn't use an older version by accident after checking the state-version. If `pkgs.nextcloud` is added manually, it needs to be declared explicitly in `services.nextcloud.package`. * The `nixos/nextcloud`-documentation contains a "Maintainer information"-chapter which describes how to roll out new Nextcloud releases and how to deal with old (and probably unsafe) versions. Closes #82056
2020-03-14 03:07:30 +00:00
};
};
in {
nextcloud21: remove EOLed by upstream in 2022-02[1]. [1] https://docs.nextcloud.com/server/23/admin_manual/release_schedule.html#older-versions
2022-03-15 20:25:44 +00:00
nextcloud21 = throw ''
Nextcloud v21 has been removed from `nixpkgs` as the support for it was dropped
by upstream in 2022-02. Please upgrade to at least Nextcloud v22 by declaring
nixos/nextcloud: drop nextcloud17, deprecate nextcloud18 Both packages will get EOLed within the lifetime of 20.09. `nextcloud17` can be removed entirely (the attribute-path is kept however to provide meaningful errors), however `nextcloud18` must be kept as `insecure` to make sure that users from `nextcloud17` can properly upgrade to `nextcloud19` on NixOS 20.09.
2020-09-20 17:06:37 +00:00
nextcloud21: remove EOLed by upstream in 2022-02[1]. [1] https://docs.nextcloud.com/server/23/admin_manual/release_schedule.html#older-versions
2022-03-15 20:25:44 +00:00
services.nextcloud.package = pkgs.nextcloud22;
nixos/nextcloud: drop nextcloud17, deprecate nextcloud18 Both packages will get EOLed within the lifetime of 20.09. `nextcloud17` can be removed entirely (the attribute-path is kept however to provide meaningful errors), however `nextcloud18` must be kept as `insecure` to make sure that users from `nextcloud17` can properly upgrade to `nextcloud19` on NixOS 20.09.
2020-09-20 17:06:37 +00:00
in your NixOS config.
nextcloud: init at 10.0.0
2016-09-21 15:55:38 +00:00
nextcloud21: remove EOLed by upstream in 2022-02[1]. [1] https://docs.nextcloud.com/server/23/admin_manual/release_schedule.html#older-versions
2022-03-15 20:25:44 +00:00
WARNING: if you were on Nextcloud 20 on NixOS 21.11 you have to upgrade to Nextcloud 21
first on 21.11 because Nextcloud doesn't support upgrades accross multiple major versions!
nextcloud20: drop The version 20 of Nextcloud will be EOLed by the end of this month[1]. Since the recommended default (that didn't raise an eval-warning) on 21.05 was Nextcloud 21, this shouldn't affect too many people. In order to ensure that nobody does a (not working) upgrade across several major-versions of Nextcloud, I replaced the derivation of `nextcloud20` with a `throw` that provides instructions how to proceed. The only case that I consider "risky" is a setup upgraded from 21.05 (or older) with a `system.stateVersion` <21.11 and with `services.nextcloud.package` not explicitly declared in its config. To avoid that, I also left the `else-if` for `stateVersion < 21.03` which now sets `services.nextcloud.package` to `pkgs.nextcloud20` and thus leads to an eval-error. This condition can be removed as soon as 21.05 is EOL because then it's safe to assume that only 21.11. is used as stable release where no Nextcloud <=20 exists that can lead to such an issue. It can't be removed earlier because then every `system.stateVersion < 21.11` would lead to `nextcloud21` which is a problem if `nextcloud19` is still used. [1] https://docs.nextcloud.com/server/20/admin_manual/release_schedule.html
2021-10-24 23:26:08 +00:00
'';
nextcloud21: init at 21.0.0, set as default version ChangeLog: https://nextcloud.com/changelog/#latest21 * Packaged 21.0.0, test-deployed it to my personal instance and tested the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file management). * Bumped the default version for unstable/21.05 to `nextcloud21`. Since `nextcloud20` was added after the release of 20.09 (and thus the default on 20.09 is still `nextcloud19`), it's now needed to upgrade across two majors. This is not a problem though since it's possible to upgrade to v20 on 20.09 already and if not, the module will guard the administrator through the upgrade with eval warnings as it's the case since 20.03. * Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
2021-02-21 23:04:23 +00:00
nextcloud22: init at 22.0.0
2021-07-08 14:43:27 +00:00
nextcloud22 = generic {
nextcloud: 22.2.5 -> 22.2.6, 23.0.2 -> 23.0.3
2022-03-23 09:32:58 +00:00
version = "22.2.6";
sha256 = "0f1d0f0cb000c51b11886be25a8adce478846c3233572fcf28b44c5d4036e235";
nextcloud22: init at 22.0.0
2021-07-08 14:43:27 +00:00
};
nextcloud23: init at 23.0.0
2021-12-02 17:24:50 +00:00
nextcloud23 = generic {
nextcloud: 22.2.5 -> 22.2.6, 23.0.2 -> 23.0.3
2022-03-23 09:32:58 +00:00
version = "23.0.3";
sha256 = "39401d400fab02a84a175ea6e995b8ed4110fbaea48c876230b4f09755a62986";
nextcloud23: init at 23.0.0
2021-12-02 17:24:50 +00:00
};
nextcloud: 21.0.0 -> 21.0.1
2021-04-09 06:56:34 +00:00
# tip: get she sha with:
# curl 'https://download.nextcloud.com/server/releases/nextcloud-${version}.tar.bz2.sha256'
nextcloud: init at 10.0.0
2016-09-21 15:55:38 +00:00
}
Reference in New Issue Copy Permalink