docs: fix Hiera nav label and stale deprecation content

_data/nav/openvox_8x.yml

@@ -255,7 +255,7 @@
     link: "designing_convenient_roles.html"
 - text: Hiera
   items:
-  - text: Hiera
+  - text: About Hiera
     link: "hiera_intro.html"
   - text: Interactive Hiera Demo
     link: "hiera_demo.html"

docs/_openvox_8x/hiera_config_yaml_3.md

@@ -29,7 +29,7 @@ This version of Puppet supports three formats for hiera.yaml --- you can use any
 
 ## Important: version 3 is deprecated
 
-Version 3 of hiera.yaml is deprecated, and we plan to remove support for it in Puppet 6.
+Version 3 of hiera.yaml is deprecated and not recommended. OpenVox 8.x still supports it for backward compatibility, but you should use [version 5][v5] instead.
 
 More importantly, it has some major problems:
 

docs/_openvox_8x/hiera_config_yaml_4.md

@@ -11,7 +11,7 @@
 
 Hiera's config file is called hiera.yaml. It configures the [hierarchy][] for a given [layer][layers] of data.
 
 This version of Puppet supports three formats for hiera.yaml --- you can use any of them, although v4 and [v3][] are deprecated. This page is about version 4, a transitional format used in Hiera 5's experimental predecessor (Puppet lookup).
 
 
 Format | Allowed in                    | Description
@@ -20,9 +20,9 @@
 v4     | Environment and module layers | Deprecated. A transitional format, used in the rough draft of Hiera 5 (when we were calling it "Puppet lookup"). Doesn't support custom backends.
 [v3][] | Global layer                  | Deprecated. The classic version of hiera.yaml, which has some problems.
 
 ## Important: version 4 is deprecated.
 
-Version 4 of hiera.yaml is deprecated, and we plan to remove support for it in Puppet 6.
+Version 4 of hiera.yaml is deprecated and not recommended. OpenVox 8.x still supports it for backward compatibility, but you should use [version 5][v5] instead.
 
 More importantly, version 4 can't use some of Hiera 5's best new features, like custom backends.
 
@@ -67,14 +67,14 @@
 
 * `name` --- Required. An arbitrary human-readable name, used for debugging and for `puppet lookup --explain`.
 
     This is also used as the default `path` if you don't specify any paths. (If the name interpolates variables, Hiera will interpolate when finding data files but leave it uninterpolated when reporting the level's name.)
 * `backend` --- Required. Which backend to use. Currently only `yaml` and `json` are supported.
 * `path` --- Optional; mutually exclusive with `paths`. The path to a data file. Can interpolate variables, to use different files depending on a node's facts.
 * `paths` --- Optional; mutually exclusive with `path`. An array of paths to data files, which can interpolate variables. This acts like multiple hierarchy levels, and is shorthand for writing consecutive levels that use the same backend and datadir.
 * `datadir` --- Optional. A one-off datadir to use instead of the default one specified at top level.
 
 ## Changes to version 4 for Hiera 5
 
 In the experimental Puppet lookup, you had to use a setting to enable Hiera: for environments you had to set `environment_data_provider = hiera` in environment.conf or puppet.conf, and for modules you had to set `"data_provider":"hiera"` in metadata.json.
 
 That's no longer necessary. As of Puppet 4.9, Puppet automatically enables Hiera for a module or environment if a hiera.yaml file is present. This works for both v4 and v5 hiera.yaml files.

docs/_openvox_8x/hiera_migrate.md

@@ -21,6 +21,8 @@
 [custom_backend_system]: ./hiera_custom_backends.html
 [functions_puppet]: ./lang_write_functions_in_puppet.html
 
+> **Note:** Hiera 5 has been the default since Puppet 5 (2017), so most OpenVox 8.x users already use it and do not need this guide. It remains here for the rare case of migrating very old Hiera 3 data.
+
 Upgrading to Hiera 5 offers some major advantages. A real environment data layer means changes to your hierarchy are now routine and testable,
 using multiple backends in your hierarchy is easier and you can make a custom backend.
 
@@ -34,7 +36,7 @@
 
 Task | Benefit
 ---- | -------
 Enable the environment layer, by giving each environment its own `hiera.yaml` file. | Future hierarchy changes are cheap and testable. The legacy `hiera()`, `hiera_array()`, etc. functions gain full Hiera 5 powers in any migrated environment, only if there is a `hiera.yaml` in the environment root.
 Convert your global `hiera.yaml` file to the version 5 format. | You can use new Hiera 5 backends at the global layer.
 Convert any experimental (version 4) `hiera.yaml` files to version 5. | Future-proof any environments or modules where you used the experimental version of Puppet lookup.
 In Puppet code, replace `hiera()`/`hiera_array()`/etc. with `lookup()`. | Future-proof your Puppet code.