no longer experimental

Author: branfosj

docs/easybuild-v5/deprecated-functionality.md

@@ -110,13 +110,18 @@ The following checksum types are deprecated and should no longer be used: `md5`,
 
 ## `EnvironmentModulesC` or `EnvironmentModulesTcl` modules tools {: #modules-tools }
 
-*(more info soon)*
+The use of the older [Environment Modules](https://modules.readthedocs.io/) versions is deprecated.
+This corresponds to setting the module tool in EasyBuild to either `EnvironmentModulesC` or
+`EnvironmentModulesTcl`.
+
+Those using Environment Modules should use at least version 4.3 or newer.
 
 ---
 
 ## GC3Pie as job backend {: #gc3pie-job-backend }
 
-*(more info soon)*
+The use of the GC3Pie job backend is deprecated. Those generating jobs from EasyBuild should use one
+of the other available backends instead, such as Slurm or PBS Python.
 
 ---
 

docs/easybuild-v5/enhancements.md

@@ -63,14 +63,16 @@ If you would like to see other types of easyconfigs added as templates, please
 
 ## Mark support for installing extensions in parallel as stable (no longer experimental) {: #parallel-extensions-install-stable }
 
-*(more info soon)*
+The support for [installing extensions in parallel][installing_extensions_in_parallel]
+no longer requires the use of the `--experimental` option.
 
 ---
 
 
 ## Mark easystack support as stable (no longer experimental) {: #easystack-stable }
 
-*(more info soon)*
+[Easystack files][easystack] are now considered stable and no longer require the use
+of the `--experimental` option.
 
 ---
 

docs/easystack-files.md

@@ -4,7 +4,7 @@ This documentation covers aspects of specifying a software stack to
 install with Easybuild with *easystack files*.
 
 !!! note
-    Some breaking changes were made to the experimental easystack support in EasyBuild v4.7.0.
+    Some breaking changes were made to the easystack support in EasyBuild v4.7.0.
 
     Easystack files must now use the `easyconfigs` top-level key to list *easyconfig filenames*,
     as opposed to the `software` top-level key and separate subkeys like `version`, `versionsuffix` and
@@ -21,7 +21,7 @@ specify to EasyBuild what to install.
 To build software with *Easystack*, type:
 
 ``` shell
-eb --easystack example.yaml --experimental
+eb --easystack example.yaml
 ```
 
 where `example.yaml` is the file with specifications that you just
@@ -136,7 +136,7 @@ easyconfigs:
 and you run with
 
 ``` shell
-eb --experimental --easystack my_easystack.yaml --dry-run
+eb --easystack my_easystack.yaml --dry-run
 ```
 
 this will have the same effect as running
@@ -163,7 +163,7 @@ they take priority over the the ones on the command line, if the same configurat
 For example, running:
 
 ``` shell
-eb --experimental --easystack my_easystack.yaml --disable-debug
+eb --easystack my_easystack.yaml --disable-debug
 ```
 
 will effectively cause `PyTorch-1.12.0-foss-2022a-CUDA-11.7.0.eb` to be installed with debug logging enabled,

docs/installing-extensions-in-parallel.md

@@ -11,10 +11,6 @@ in the background, to exploit the availability of multiple cores.
 To let EasyBuild install extensions in parallel, the
 `parallel-extensions-install` configuration option must be enabled.
 
-In addition, since the support for installing extensions in parallel is
-an experimental feature, the `experimental` configuration option must be
-also be enabled (see also [Experimental features][experimental_features]).
-
 How many extension installations should be started (at maximum) at the
 same time is controlled by the `parallel` configuration option.
 
@@ -45,9 +41,6 @@ There are a couple of caveats and known issues with installing
 extensions in parallel, which we hope to resolve in future EasyBuild
 releases.
 
-This is also why the support for installing extensions in parallel is
-currently marked as an experimental feature.
-
 ### Only works for R extensions {: #installing_extensions_in_parallel_caveats_known_issues_only_r }
 
 The support for installing extensions in parallel currently only works