Add OpenVox 9.x docs collection as a preview (latest stays on 8.x)

[miharp]

Summary

OpenVox 9 has shipped beta packages (currently 9.0.0-beta2) with a stable
release targeted for August. This stands up the docs/_openvox_9x collection per the
copy-on-major-release model in MAINTAINING.md — Phase 1 of the two-phase
cutover: the new version is browsable at /openvox/9.x/, while /openvox/latest/
keeps serving OpenVox 8 until 9.0 goes GA (Phase 2, a separate follow-up PR).

• Copied docs/_openvox_8x → docs/_openvox_9x and its nav file
• Swept the copy for "OpenVox 8"/"8.x" strings and reviewed each hit in context
  (not a blind find/replace — see MAINTAINING.md's content-sweep step):
  • Mechanical title/prose bumps (index, install docs, nav headings)
  • Rewrote release_notes.markdown for the 9.x prerelease series
    (9.0.0-alpha1/alpha2/beta1/beta2) instead of carrying over 8.x's
    release history
  • Cleared known_issues.md (the one listed issue was specific to 8.26.2)
  • supported_platforms.md: shared-actions/platforms.json hasn't frozen a
    dedicated 9.x key yet, so the 9.x table sources from main with a note
    that it isn't final
  • Bumped the hiera.yaml v3/v4 backward-compat notes to 9.x (now verified
    against the 9.0.0-beta2 source: the v3/v4 config parsing in
    lib/puppet/pops/lookup/hiera_config.rb is still present; beta2's hiera
    removals are the deprecated hiera indirector and the data-binding
    settings, not the file-format support)
• Registered the collection in _config.yml, _data/nav_map.yml, and
  _data/navigation.yml
• Added the 9x version entry to _data/products.yml, pinned to 9.0.0-beta2
• Generated reference docs from the pinned tag and verified with a full
  jekyll build + rake test:links, plus an htmlproofer pass over the built
  9.x tree (which test:links doesn't cover — it only proofs latest trees).
  That pass caught one stale link: custom_types.markdown pointed at the
  pluginsync setting, which was removed in 9.x; rewrote that step for
  current behavior
• Swept the 9.0.0 prerelease changelogs (alpha1 → beta2) against the authored
  pages for behavioral claims that a version-string sweep can't catch. Four
  pages needed fixes: the reports default is now none (openvox#583), the
  puppet agent --configprint command was removed along with the configprint
  setting (openvox#374; now puppet config print), data_binding_terminus
  was removed rather than deprecated (openvox#385), and agents no longer fall
  back to the default server hostname puppet (openvox#536)
• Ported Document the remaining undocumented data types #425's data-type doc updates (merged to 8.x after this branch's copy
  was made) into the 9.x collection, so the two trees are content-synced as of
  this writing, and added a Phase 2 runbook step to MAINTAINING.md that
  re-checks for and ports 8.x drift before the GA promotion — this bounds any
  docs freeze to the window between that final check and the promotion merge

Related to #325.

Pages with content changes vs 8.x

Everything else in docs/_openvox_9x is either an unmodified copy of the 8.x
authored page or a freshly generated reference page. These are the only pages with
hand-edited content, per the sweep above:

Page	What changed
index.md	Title bump, added a prerelease callout
release_notes.markdown	Rewritten for the 9.x prerelease series (alpha1/alpha2/beta1/beta2) instead of 8.x's release history
known_issues.md	Cleared the one listed issue (specific to 8.26.2)
supported_platforms.md	Single "OpenVox 9.x (in development)" table sourced from platforms.json's main key, since it hasn't frozen a 9.x key yet
upgrade_minor.md	Title bump, added a breaking-changes callout pointing at the release notes
install_pre.markdown	Version bump; DNS step now says to always set server explicitly, since 9.x removed the default puppet hostname fallback (openvox#536)
hiera_config_yaml_3.md	Backward-compat note bumped to 9.x (see caveat above)
hiera_config_yaml_4.md	Backward-compat note bumped to 9.x (see caveat above)
hiera_migrate.md	Backward-compat note bumped to 9.x; data_binding_terminus guidance reworded as pre-upgrade cleanup, since the setting was removed in 9.x (openvox#385)
custom_types.markdown	Removed the link to the pluginsync setting (removed in 9.x, so the anchor no longer exists) and rewrote the step for current behavior
reporting_about.md	Reworded the configuring-reporting paragraph: the reports default changed from store to none in 9.x (openvox#583), so report processing is opt-in
lang_relationships.markdown	puppet agent --configprint graphdir → puppet config print graphdir (option removed with the configprint setting, openvox#374)
services_commands_windows.markdown	puppet agent --configprint SETTING → puppet config print SETTING (same removal)
_data/nav/openvox_9x.yml	Sidebar section heading and "Upgrading OpenVox 9" link text

Actual content diffs (8.x → 9.x) — GitHub's per-PR file view shows these paths as 100% new since they didn't exist on master; these are real diff -u output against the corresponding 8.x source. (release_notes.markdown isn't included here — it's a full rewrite, not a targeted edit; see its diff link in the table above.)

index.md

--- docs/_openvox_8x/index.md
+++ docs/_openvox_9x/index.md
@@ -1,8 +1,11 @@
 ---
 layout: default
-title: "OpenVox 8"
+title: "OpenVox 9"
 ---
 
+> **OpenVox 9 is in prerelease.** See the [release notes](release_notes.html) for the
+> current build and expect breaking changes before the stable 9.0.0 release.
+
 OpenVox is a community-maintained implementation of Puppet — a configuration management system for Linux, Unix, and Windows. It manages system state through a declarative language, compiling node-specific catalogs and enforcing them on each managed host.
 
 When Perforce discontinued public distribution of Puppet Open Source in late 2024, Overlook InfraTech stepped in with community packaging, and the project was subsequently adopted under [Vox Pupuli](https://voxpupuli.org/) stewardship as OpenVox. A Puppet Standards Steering Committee guides language and feature evolution going forward.

known_issues.md

--- docs/_openvox_8x/known_issues.md
+++ docs/_openvox_9x/known_issues.md
@@ -1,13 +1,9 @@
 ---
 layout: default
 toc_levels: 1234
-title: "OpenVox 8 known issues"
+title: "OpenVox 9 known issues"
 ---
 
-As known issues are discovered in OpenVox 8 and its patch releases, they'll be added to the [project's issue tracker](https://github.com/OpenVoxProject/openvox/issues). Once a known issue is resolved, it is listed as a resolved issue in the release notes for that release, and removed from this list.
+As known issues are discovered in OpenVox 9 and its patch releases, they'll be added to the [project's issue tracker](https://github.com/OpenVoxProject/openvox/issues). Once a known issue is resolved, it is listed as a resolved issue in the release notes for that release, and removed from this list.
 
-## OpenVox 8.26.2
-
-### `openvox --version` reports 8.26.1
-
-After installing `openvox-agent` 8.26.2, running `puppet --version` reports `8.26.1` instead of `8.26.2`. The agent itself is at the correct version; only the version string returned by `--version` is incorrect. See [issue #415](https://github.com/OpenVoxProject/openvox/issues/415).
+No known issues have been reported for OpenVox 9 yet.

supported_platforms.md

--- docs/_openvox_8x/supported_platforms.md
+++ docs/_openvox_9x/supported_platforms.md
@@ -28,29 +28,20 @@
 A dagger (†) marks operating systems with FIPS-validated builds. FIPS builds are
 x86-64 only.
 
-## OpenVox 8.x
+## OpenVox 9.x
 
-{% assign rows = site.data.supported_platforms["8.x"] %}
+> **In development.** OpenVox 9 is in prerelease, and `shared-actions` has not yet
+> frozen a dedicated `9.x` platform list — this table reflects the current
+> development target and can change before the stable 9.0.0 release.
 
+{% assign rows = site.data.supported_platforms["main"] %}
+
 <!-- markdownlint-disable MD055 MD056 -->
 
 | Operating system | openvox-agent / OpenBolt | openvox-server / OpenVoxDB |
 | --- | --- | --- |
 {% for r in rows %}| {{ r.os }}{% if r.fips %} †{% endif %} | {% if r.agent_bolt %}{{ r.agent_bolt | join: ", " }}{% else %}—{% endif %} | {% if r.server_db %}✓{% else %}—{% endif %} |
 {% endfor %}
-
-## Next major version (in development)
-
-> **In development.** These are the platforms targeted by the next major OpenVox
-> release while it is being developed. The list can change before that release is
-> final.
-
-{% assign rows = site.data.supported_platforms["main"] %}
-
-| Operating system | openvox-agent / OpenBolt | openvox-server / OpenVoxDB |
-| --- | --- | --- |
-{% for r in rows %}| {{ r.os }}{% if r.fips %} †{% endif %} | {% if r.agent_bolt %}{{ r.agent_bolt | join: ", " }}{% else %}—{% endif %} | {% if r.server_db %}✓{% else %}—{% endif %} |
-{% endfor %}
 <!-- markdownlint-enable MD055 MD056 -->
 
 > **Enterprise Linux** covers RHEL and its rebuilds (AlmaLinux, Rocky Linux, Oracle

upgrade_minor.md

--- docs/_openvox_8x/upgrade_minor.md
+++ docs/_openvox_9x/upgrade_minor.md
@@ -1,13 +1,16 @@
 ---
 layout: default
-title: "Upgrading OpenVox 8"
+title: "Upgrading OpenVox 9"
 ---
 
-Use this page for routine OpenVox 8 upgrades and for in-place migrations from the
+Use this page for routine OpenVox 9 upgrades and for in-place migrations from the
 legacy Puppet packages to OpenVox packages.
 
-OpenVox 8 is functionally equivalent to modern Puppet in day-to-day operation. The
-main migration rule is that a host cannot have both Puppet and OpenVox packages
+> **OpenVox 9 is a major version** and includes breaking changes relative to OpenVox
+> 8 — see the [release notes](./release_notes.html) before upgrading a production
+> host. The steps below cover the mechanics of the upgrade itself.
+
+The main migration rule is that a host cannot have both Puppet and OpenVox packages
 installed at the same time. Back up `/etc/puppetlabs/` before you start.
 
 ## Recommended order

install_pre.markdown

--- docs/_openvox_8x/install_pre.markdown
+++ docs/_openvox_9x/install_pre.markdown
@@ -9,7 +9,7 @@
 [openvox_server]: /openvox-server/latest/install_from_packages.html
 [server_setting]: ./configuration.html#server
 
-OpenVox 8 uses the same commands and configuration paths as modern Puppet releases.
+OpenVox 9 uses the same commands and configuration paths as modern Puppet releases.
 You can keep using your existing tooling and `/etc/puppetlabs/` configuration, but
 you cannot install both Puppet and OpenVox on the same system at the same time.
 
@@ -42,9 +42,9 @@
 5. Check DNS, certificates, and networking.
 
    In agent-server deployments, agents must be able to reach the server on port
-   `8140`. Forward and reverse DNS should be correct for every node. If you want
-   agents to use the default server name, make sure `puppet` resolves correctly;
-   otherwise set the [`server` setting][server_setting] explicitly.
+   `8140`. Forward and reverse DNS should be correct for every node. Set the
+   [`server` setting][server_setting] explicitly on every agent: starting in
+   OpenVox 9, agents no longer fall back to the hostname `puppet` by default.
 
 6. Verify time synchronization on the certificate authority.
 

hiera_config_yaml_3.md

--- docs/_openvox_8x/hiera_config_yaml_3.md
+++ docs/_openvox_9x/hiera_config_yaml_3.md
@@ -29,7 +29,7 @@
 
 ## Important: version 3 is deprecated
 
-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.
+Version 3 of hiera.yaml is deprecated and not recommended. OpenVox 9.x still supports it for backward compatibility, but you should use [version 5][v5] instead.
 
 More importantly, it has some major problems:
 

hiera_config_yaml_4.md

--- docs/_openvox_8x/hiera_config_yaml_4.md
+++ docs/_openvox_9x/hiera_config_yaml_4.md
@@ -22,7 +22,7 @@
 
 ## Important: version 4 is deprecated
 
-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.
+Version 4 of hiera.yaml is deprecated and not recommended. OpenVox 9.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.
 

hiera_migrate.md

--- docs/_openvox_8x/hiera_migrate.md
+++ docs/_openvox_9x/hiera_migrate.md
@@ -21,7 +21,7 @@
 [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.
+> **Note:** Hiera 5 has been the default since Puppet 5 (2017), so most OpenVox 9.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.
@@ -55,10 +55,10 @@
   If an updated version of the backend is coming out soon, wait. If you're using an off-the-shelf custom backend, check its website or contact its developer.
   If you developed your backend in-house, read the [documentation about writing Hiera 5 backends][backends].
 
-- **Custom `data_binding_terminus` users** — Upgrade now, and replace it with a Hiera 5 backend as soon as possible.
-  There's a deprecated `data_binding_terminus` setting in `puppet.conf` which changes the behavior of automatic class parameter lookup.
-  It can be set to `hiera` (normal), `none` (deprecated; disables auto-lookup), or the name of a custom plugin.
-  Once you have a Hiera 5 backend, integrate it into your hierarchies and delete the `data_binding_terminus` setting.
+- **Custom `data_binding_terminus` users** — Replace it with a Hiera 5 backend before upgrading.
+  Older versions had a deprecated `data_binding_terminus` setting in `puppet.conf` which changed the behavior of automatic class parameter lookup; it could be set to `hiera` (normal), `none` (disables auto-lookup), or the name of a custom plugin.
+  That setting (and the custom-plugin mechanism behind it) was removed in OpenVox 9.
+  Move the custom backend's data into a Hiera 5 backend, integrate it into your hierarchies, and delete the `data_binding_terminus` setting before you upgrade.
 
 Related topics: [environment data layer][layers], [hiera.yaml (v5) eyaml usage][eyaml_v5], [writing Hiera 5 backends][backends], [puppet.conf][puppet_conf], [automatic class parameter lookup][automatic].
 

custom_types.markdown

--- docs/_openvox_8x/custom_types.markdown
+++ docs/_openvox_9x/custom_types.markdown
@@ -7,7 +7,6 @@
 [module]: modules_fundamentals.html
 [custom_functions]: lang_write_functions_in_puppet.html
 [custom_facts]: /openfact/latest/custom_facts.html
-[pluginsync]: configuration.html#pluginsync
 [symbol]: http://www.ruby-doc.org/core/Symbol.html
 [ruby_block]: http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/
 [markdown]: http://commonmark.org/
@@ -42,11 +41,9 @@
 1. The type and providers must be present in a [module][] on the OpenVox Server server. Like other types of plugin (such as [custom functions][custom_functions] and [custom facts][custom_facts]), they should go in the module's `lib` directory:
     * Type files should be located at `lib/puppet/type/<TYPE NAME>.rb`.
     * Provider files should be located at `lib/puppet/provider/<TYPE NAME>/<PROVIDER NAME>.rb`.
-2. If you are using an agent/master Puppet deployment, each agent node must have its [`pluginsync` setting][pluginsync] in puppet.conf set to `true`.
-    * Starting in Puppet 3.0, this setting defaults to true.
-    * In Puppet 2.x, it defaults to false and must be explicitly enabled.
+2. In an agent/server deployment, agent nodes automatically sync plugins (including custom types and providers) from the server's modules at the start of each run, so no configuration is needed. (The old `pluginsync` setting that controlled this was removed in OpenVox 9.)
 
-In masterless Puppet using puppet apply, pluginsync is not required, but the module containing the type and providers must be present on each node.
+When running without a server using puppet apply, plugin sync is not involved, but the module containing the type and providers must be present on each node.
 
 See [the Plugins In Modules page](./plugins_in_modules.html) for more details on distributing custom types and facts via modules.
 

reporting_about.md

--- docs/_openvox_8x/reporting_about.md
+++ docs/_openvox_9x/reporting_about.md
@@ -28,8 +28,8 @@
 
 An OpenVox agent sends reports by default. You can turn off reporting by changing the [`report`][report] setting in an agent's [`puppet.conf`][puppet.conf].
 
-On OpenVox Server servers (and nodes running Puppet apply), you can configure enabled report processors as a comma-separated list in the [`reports`][reports] setting. The default `reports` value is 'store',
-which stores them in the configured [`reportdir`][reportdir]. You can also turn off reports entirely by setting `reports` to 'none'.
+On OpenVox Server servers (and nodes running Puppet apply), you can configure enabled report processors as a comma-separated list in the [`reports`][reports] setting. Starting in OpenVox 9, the default `reports` value is 'none', which means received reports are discarded without processing. To process reports, set `reports` to one or more processors — for example, 'store'
+saves each report to the configured [`reportdir`][reportdir].
 
 ## Practical reporting for beginners
 

lang_relationships.markdown

--- docs/_openvox_8x/lang_relationships.markdown
+++ docs/_openvox_9x/lang_relationships.markdown
@@ -320,4 +320,4 @@
 Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
 ```
 
-To locate the directory containing the graph files, run `puppet agent --configprint graphdir`.
+To locate the directory containing the graph files, run `puppet config print graphdir`.

services_commands_windows.markdown

--- docs/_openvox_8x/services_commands_windows.markdown
+++ docs/_openvox_9x/services_commands_windows.markdown
@@ -111,7 +111,7 @@
 - The `puppet.conf` configuration file supports Windows and *nix line endings, (CR-LF) and (LF), respectively, and does not support Byte Order Mark (BOM). The file encoding must either be UTF-8 or the current Windows encoding, for example, Windows-1252 code page.
 - Specifying file owner, group, or mode for file-based settings is not supported on Windows
 - The `puppet.conf` file is allowed to use Windows-CRLF line endings as well as *nix-style LF line endings.
-  - You can get configuration settings by running: `puppet agent --configprint SETTING`
+  - You can get configuration settings by running: `puppet config print SETTING`
   - You can set configuration settings by running: `puppet config set SETTING VALUE --section SECTION`
 - Common configuration settings are: `certname`, `server`, and `runinterval`
 - You must restart the Puppet Agent service after making any changes to Puppet’s `runinterval` config file.

Screenshots

Local jekyll serve render of the pages with content changes:

index.md

(screenshot: openvox9-index.png)

release_notes.markdown

(screenshot: openvox9-release-notes.png)

supported_platforms.md

(screenshot: openvox9-supported-platforms.png)

upgrade_minor.md

(screenshot: openvox9-upgrade-minor.png)

Test plan

• bundle exec rake references:openvox VERSION=9.0.0-beta2 COLLECTION=_openvox_9x INSTALLPATH=docs
• bundle exec jekyll build — confirmed /openvox/8.x/, /openvox/9.x/, and
  /openvox/latest/ all render, with latest still serving OpenVox 8
• bundle exec rake test:links — passes (this task only proofs latest
  trees, so it doesn't cover 9.x yet — a known, already-tracked gap)
• htmlproofer (same config as test:links) over the built
  _site/openvox/9.x tree — passes after the custom_types.markdown
pluginsync fix
• Visual review of the changed pages (index, release notes, known issues,
  supported platforms, upgrade guide) via local jekyll serve — see
  screenshots above
• Reviewer: sanity-check the hiera v3/v4 backward-compat wording called
  out above — verified against the 9.0.0-beta2 source (see the sweep
  note above)

[binford2k]

Has the release notes generation process (including CVE fixes) been updated to handle this?

[miharp]

@binford2k

Has the release notes generation process (including CVE fixes) been updated to handle this?

We do not have automation for release notes, they are hand crafted for each release.