Fixes #21750: versions in Rudder doc are invalid

src/reference/modules/installation/pages/container.adoc

@@ -10,7 +10,7 @@ read more about plugins on https://www.rudder.io/software/plugins/[our website].
 
 == Rudder relay
 
-Starting with Rudder 6.2, there is a Docker image for running a fully containerized relay.
+There is a Docker image for running a fully containerized relay.
 
 It is still in technical preview state, and we would like to discuss your container use cases
 on https://chat.rudder.io[our chat room] to improve our container support, especially in the context of
@@ -31,7 +31,7 @@ You can also build it from the https://github.com/Normation/rudder/tree/master/d
 Specify a version to build with:
 
 ```bash
-docker build --build-arg VERSION=6.2.0 .
+docker build --build-arg VERSION=7.2.5 .
 ```
 
 ### Configuration

src/reference/modules/installation/pages/quick_install.adoc

@@ -33,13 +33,13 @@ Usage rudder-setup (add-repository|setup-agent|setup-server|upgrade-agent|upgrad
   Currently supported : Debian, Ubuntu, RHEL, Fedora, Centos, Amazon, Oracle, SLES
 
   rudder_version : x.y or x.y.z or x.y-nightly or ci/x.y or lts or latest
-       x.y:            the latest x.y release (ex: 3.2)
-       x.y.z:          the exact x.y.z release (ex: 3.2.1)
-       x.y.z~a:        the latest x.y.z pre-release where a can be alpha1, beta1, rc1... (ex: 4.0.0~rc1) 
-       x.y-nightly:    the latest public x.y nightly build (ex: 3.2-nightly)
-       ci/x.y.z:       the latest development x.y.z release build (ex: ci/3.2.16)
-       ci/x.y.z~a:     the latest development x.y.z pre-release build (ex: ci/4.0.0~rc1)
-       ci/x.y-nightly: the latest development x.y nightly build (ex: ci/5.1-nightly)
+       x.y:            the latest x.y release (ex: 7.2)
+       x.y.z:          the exact x.y.z release (ex: 7.2.5)
+       x.y.z~a:        the latest x.y.z pre-release where a can be alpha1, beta1, rc1... (ex: 7.3.0~rc1) 
+       x.y-nightly:    the latest public x.y nightly build (ex: 7.2-nightly)
+       ci/x.y.z:       the latest development x.y.z release build (ex: ci/7.2.5)
+       ci/x.y.z~a:     the latest development x.y.z pre-release build (ex: ci/7.3.0~rc1)
+       ci/x.y-nightly: the latest development x.y nightly build (ex: ci/7.3-nightly)
        latest:         the latest stable version
 
   Environment variables

src/reference/modules/installation/pages/requirements.adoc

@@ -184,7 +184,7 @@ compliance from node, a safe estimation of disk usage is 200MB as a baseline, pl
 
 Note: When using Syslog reporting, ticking "Log all reports received to `/var/log/rudder/reports/all.log`"
 under the *Administration -> Settings* tab in the Rudder web interface will record all logs from nodes in a text file,
-on top from the SQL database. This uses a lot of disk space, and is disabled by default in Rudder 6.1.
+on top from the SQL database. This uses a lot of disk space, and is disabled by default.
 
 =======
 

src/reference/modules/installation/pages/upgrade/notes.adoc

@@ -230,3 +230,4 @@ If you have an external postgresql database and you upgrade from pre-7.0 you nee
 Direct upgrades from 6.1 versions and older are no longer supported on 7.2.
 If you are still running one of those, either on servers or nodes,
 please first upgrade to one of the supported versions, and then upgrade to 7.2.
+

src/reference/modules/reference/pages/architecture.adoc

@@ -73,9 +73,7 @@ event is sent to in inventory watcher process which:
 - if the file is a signature (respectively an inventory), it waits for the
   corresponding inventory (respectively signature) for up to 10s,
 - if only the signature is present, nothing is done (only a log),
-- if only the inventory file is present, the processing is done in
-  "compatibility" mode to support rudder agent below version 5.0,
-- if the pair is present, both are processed together.
+- if the pair is present, both are processed together. 
 - processing starts by parsing inventory file and check for mandatory
   elements (especially `<RUDDER>` tag and content)
 - then, inventory is queued to be saved in LDAP.

src/reference/modules/reference/pages/build.adoc

@@ -27,7 +27,7 @@ Choose the branch to build
 
 # For branch x.y
 #git checkout branches/rudder/x.y
-# 7.0 is still master when this documentation is written
+# 7.3 is still master when this documentation is written
 git checkout master
 cd rudder-agent
 

src/reference/modules/reference/pages/techniques.adoc

@@ -205,9 +205,9 @@ The display of this component key will be the value from the metadata and not th
    * *datetime* : display a JQuery calendar and check date format
    * *boolean* : display a checkbox
    * *mail* : only accept emails
-   * *ip* : only accept ips. Before Rudder 3.1.14, 3.2.7 and 4.0.0, "ip" was accepting only IPv4 ip. Since these releases, it accepts both IPv4 and IPv6 format. <br />
-   *  *ipv4* [since Rudder 3.1.14, 3.2.7, 4.0.0]: only accept IPv4 formatted IPs
-   * *ipv6* [since Rudder 3.1.14, 3.2.7, 4.0.0]: only accept IPv6 formatted IPs
+   * *ip* : only accept ips, support both IPv4 and IPv6 format.
+   *  *ipv4* : only accept IPv4 formatted IPs
+   *  *ipv6* : only accept IPv6 formatted IPs
    * *size-<unit>* : (size-b, size-kb, size-mb, size-gb ou size-tb)
    * *raw* : the content of this field will not be escaped when written in the policies (Rudder >= 2.6)
    * *password* : the content of this field will be handled as a password, and thus be hidden and transformed if necessary (see "Password handling" below)

src/reference/modules/usage/pages/advanced_configuration_management.adoc

@@ -62,7 +62,7 @@ Two version of each of these files is conserved: the oldest one has a `.old` suf
 ==== `webapp` logs
 
 Rudder web application logs located in `/var/log/rudder/webapp/yyyy_MM_dd.stderrout.log` contains information
-about policy generation process. In rudder 6.0, all policy generation logs are gathered under `policy.generation`
+about policy generation process. All policy generation logs are gathered under `policy.generation`
 namespace (with optionally more precise namespace, like `policy.generation.timing` for timing information, or
 `policy.generation.update` for updated nodes, etc).
 By default, policy generation logs when it starts with generic information about system:
@@ -223,8 +223,7 @@ If you want to run post hooks by hand, you can use the following command:
 [[_server_event_hooks]]
 == Server Event Hooks
 
-Rudder 4.1 introduces the possibility to execute files (hooks), typically scripts,
-when some predefined event occurs on Rudder.
+Files (hooks), typically scripts, can be executed on the server, when some predefined event occurs on Rudder.
 
 include::{partialsdir}/dyn/hooks.adoc[leveloffset=+3]
 
@@ -331,7 +330,7 @@ But use: "05. My general security rule" and "40. Check ssh configuration"
 
 == Share files between nodes
 
-Rudder 4.1 introduced a way to share files from one node to another.
+There is a way to share files from one node to another.
 It allows a node to send a file to its relay, which will make it available
 for another target node, that has to specifically download it.
 

src/reference/modules/usage/pages/advanced_node_management.adoc

@@ -363,11 +363,9 @@ load across your infrastructure.
 It is quite common to need to gather information on your nodes that are not present
 in the standard Rudder inventory information.
 
-As of Rudder 4.3.0, you can get more information about a node thanks to
+You can obtain more information about a node thanks to
 `inventory hooks`. These information will be available as standard *node properties*.
 
-Starting from 6.0.3, the inventory extension is also available on Windows based agents.
-
 
 === Overview
 

src/reference/modules/usage/pages/node_management.adoc

@@ -242,9 +242,7 @@ You will have to add that search line to your request:
 
 === Node properties search
 
-Node properties are special because they support both `key=value` and `key=JSON` content.
-As of Rudder 4.3.2, we have the possibility to choose among three operator given the use case,
-so let's see which is the best on each case.
+Node properties are special because they support both `key=value` and `key=JSON` content. There are three search operators available:
 
 ==== Check for property existence: [Name equals]
 
@@ -311,7 +309,7 @@ the following examples allow to fill different purposes:
 [[search-nodes-properties-json-path, JSON Path queries on Node Properties]]
 ==== JSON Path queries on Node Properties
 
-Since Rudder 4.3.2, you can use a JSON path query to lookup nodes based of specific feature
+You can use a JSON path query to lookup nodes based of specific feature
 of the JSON value of a node property.
 
 The operator is +Name:JSON Path+ and the general usage is:

src/reference/modules/usage/pages/variables.adoc

@@ -314,8 +314,6 @@ NOTE: If you want to use an `inventory variable` that you gathered through a
 xref:usage:advanced_node_management.adoc#extend-nodes-inventory[node inventory hook], you need to use `${node.properties[hook_first_level_key]}` syntax.
 You can also check in node `properties` tab for the name of the properties you are looking for.
 
-NOTE: These variables have been introduced in Rudder 5.0.13, if you are using a previous version of Rudder, please use *system variables*, described in next section
-
 [WARNING]
 
 ====
@@ -532,7 +530,7 @@ System variables like `ipv4[eth0]` are actually STRINGS in jinja2, not JSON, so
 |Node's domain as discovered by the agent
 |===
 
-There are also more variables available, all documented in https://docs.cfengine.com/docs/3.15/reference-special-variables-sys.html[this page].
+There are also more variables available, all documented in https://docs.cfengine.com/docs/3.18/reference-special-variables-sys.html[this page].
 
 ====== Constants
 
@@ -633,7 +631,7 @@ The resulting properties will be:
 
 Agents can define variables:
 
-* For the Linux agent, https://docs.cfengine.com/docs/3.15/reference-special-variables-sys.html[CFEngine system variable] are available.
+* For the Linux agent, https://docs.cfengine.com/docs/3.18/reference-special-variables-sys.html[CFEngine system variable] are available.
 
 * For the Windows agent, no specific variables are provided.