# Release 22.05 (“Quokka”, 2022.05/??) {#sec-release-22.05}
In addition to numerous new and upgraded packages, this release has the following highlights:
- Support is planned until the end of December 2022, handing over to 22.11.
## Highlights {#sec-release-22.05-highlights}
## New Services {#sec-release-22.05-new-services}
- [aesmd ](https://github.com/intel/linux-sgx#install-the-intelr-sgx-psw ), the Intel SGX Architectural Enclave Service Manager. Available as [services.aesmd ](#opt-services.aesmd.enable ).
## Backward Incompatibilities {#sec-release-22.05-incompatibilities}
- `pkgs.ghc` now refers to `pkgs.targetPackages.haskellPackages.ghc` .
This *only* makes a difference if you are cross-compiling and will
ensure that `pkgs.ghc` always runs on the host platform and compiles
for the target platform (similar to `pkgs.gcc` for example).
`haskellPackages.ghc` still behaves as before, running on the build
platform and compiling for the host platform (similar to `stdenv.cc` ).
This means you don't have to adjust your derivations if you use
`haskellPackages.callPackage` , but when using `pkgs.callPackage` and
taking `ghc` as an input, you should now use `buildPackages.ghc`
instead to ensure cross compilation keeps working (or switch to
`haskellPackages.callPackage` ).
- `pkgs.emacsPackages.orgPackages` is removed because org elpa is deprecated.
The packages in the top level of `pkgs.emacsPackages` , such as org and
org-contrib, refer to the ones in `pkgs.emacsPackages.elpaPackages` and
`pkgs.emacsPackages.nongnuPackages` where the new versions will release.
- The `wafHook` hook now honors `NIX_BUILD_CORES` when `enableParallelBuilding` is not set explicitly. Packages can restore the old behaviour by setting `enableParallelBuilding=false` .
- `pkgs.claws-mail-gtk2` , representing Claws Mail's older release version three, was removed in order to get rid of Python 2.
Please switch to `claws-mail` , which is Claws Mail's latest release based on GTK+3 and Python 3.
## Other Notable Changes {#sec-release-22.05-notable-changes}
- The option [services.redis.servers ](#opt-services.redis.servers ) was added
to support per-application `redis-server` which is more secure since Redis databases
are only mere key prefixes without any configuration or ACL of their own.
Backward-compatibility is preserved by mapping old `services.redis.settings`
to `services.redis.servers."".settings` , but you are strongly encouraged
to name each `redis-server` instance after the application using it,
instead of keeping that nameless one.
Except for the nameless `services.redis.servers.""`
still accessible at `127.0.0.1:6379` ,
and to the members of the Unix group `redis`
through the Unix socket `/run/redis/redis.sock` ,
all other `services.redis.servers.${serverName}`
are only accessible by default
to the members of the Unix group `redis-${serverName}`
through the Unix socket `/run/redis-${serverName}/redis.sock` .
