Declare OpenBolt 5.x end of life when 9.0.0 ships #356

Summary

OpenBolt 9.0.0 is close and there is no plan for further 5.x releases, because openbolt-runtime now builds from the 9.x components. OpenVox 8 is still supported and still receiving security releases (8.31.2 on October 29). OpenBolt 5.6.0, from June, is drifting behind on the same components, and nothing tells its users what to do next.

This issue asks for an explicit statement when 9.0.0 ships, so the docs can carry it. The answer that fits most users is "move to OpenBolt 9", and I have checked that it works against OpenVox 8 agents. A 5.x maintenance line is the alternative if the team wants to keep users who cannot move to 9; I am offering to do that work.

Where 5.6.0 stands

From the SBOMs in openvox-sbom-tools, OpenBolt 5.6.0 next to the agent an OpenVox 8 operator runs today:

OpenBolt bundles its own Ruby and OpenSSL and installs into its own directory, so the agent major on the Bolt host does not decide which OpenBolt can run there; the 5.x install page already documents 5.x on OpenVox 9 hosts. The openvox ~> 9.0 dependency of 9.0.0.pre.rc1 is the Puppet library OpenBolt compiles catalogs with, not a requirement on the host's agent. The question is therefore not whether OpenVox 8 users can run OpenBolt 9, but whether the project says they should.

Recommended: OpenBolt 9 for everyone, and an explicit end of life for 5.x

I checked the part that could have broken: OpenBolt 9.0.0.pre.rc1 (the gem, with openvox 9.2.1) on a workstation, against two openvox-agent 8.30.0 targets (AlmaLinux 9 and Ubuntu 24.04). bolt command run, the facts task, and bolt apply all work. The catalog compiled by the 9 host is applied by the 8.30.0 agent, a second apply reports no changes, a module type (stdlib file_line) synced from the 9 host loads on the 8 agent, and apply_prep leaves the installed agents alone (it only rejects agents older than major 6).

One thing OpenVox 8 users need to know: apply_prep installs a missing agent with openvox_bootstrap::install, which defaults to the newest collection. A fleet on OpenVox 8 should set collection: openvox8 in the puppet_library plugin hook, or a bare target gets a 9 agent. That is a one-line project setting and belongs in the 9.x docs.

With that, the statement is: OpenBolt 5.x ends with 5.6.0 and receives no further releases, including security fixes; OpenBolt 9 is the supported release for OpenVox 8 and OpenVox 9 fleets alike. The docs then tell OpenVox 8 operators to move to OpenBolt 9 and the 5.x pages carry an end-of-life notice. What I want to avoid is 5.x stopping without any statement.

Alternative: a 5.x maintenance line

For users who cannot move to OpenBolt 9: plans that need work for the Puppet 9 language, the PCP transport removal (#332), the Windows build change, or Ruby 3.4 or newer for gem installs. If the team wants to keep them, most of the machinery is still in place.

Runtime. puppet-runtime builds agent-runtime-8.x and agent-runtime-main side by side from one branch, and openbolt-runtime on demand from the same branch. The openbolt-runtime project switched from Ruby 3.2 and OpenSSL 3.0 to Ruby 4.0 and OpenSSL 3.5 between tags 2026.09.02.1 and 2026.10.15.1. An openbolt-runtime-5.x project, which is the pre-switch configs/projects/openbolt-runtime.rb under a new name, added to the build.yml project choices next to the other three, gives a 5.x runtime that picks up the same OpenSSL 3.0 and Ruby 3.2 patches the 8.x agent runtime gets. No branch and no reverts in puppet-runtime.

OpenBolt and packaging. A 5.x branch cut at e0c0473, the last commit before the OpenBolt 9 work (#332). The packaging lives in this repo under packaging/ since #156 (openbolt-vanagon is archived), so the branch carries its own copy. Its configs/projects/openbolt.rb reads puppet-runtime.json and fetches openbolt-runtime-<version>.<platform> from the runtime location; on the branch that becomes the new tag and the openbolt-runtime-5.x- prefix, two lines. build.yml already offers the 8.x branch choice, with the comment "Only use 8.x if we ever have to do another OpenBolt 5.x release", and shared-actions' build_vanagon.yml maps it to the 8.x platform list and runs vanagon on Ruby 3.2. prepare_release.yml and release.yml already take base-branch.

What 5.7.0 would contain. Everything merged between 5.6.0 and the cut, 58 commits: the spinner truncation fix (#315), bindata < 3.0 (#273), the pup.pt link cleanup (#279), the setup.ps1 removal (#284), puppet-runtime 2026.09.02.1 (#292), and about thirty bundled module updates including the stdlib 10, service 4, package 4, reboot 6, puppet_conf 3, and scheduled_task 5 majors. Plus cherry-picks that apply cleanly to the cut (checked with git merge-tree, tests not yet run): the three documentation fixes merged on October 29 (#354, #353, #280), the JSON target list on the CLI (#281), #335, the renovate updates #347, #348, #350, and #351, and two commits from inside #332 that are not 9-specific, c499537 (remove PCP remnants) and b088c37 (Socket.tcp timeout as connection timeout). Left out as 9-only: the rest of #332, #333, #338, #339, #340 (Ruby >= 3.4), and #341.

After 5.7.0, the line would be security-only: a runtime promotion when the 8.x agent runtime gets one, and a release, for as long as OpenVox 8 is supported.

I can do the branch, the runtime project, the cherry-picks, and the release pull requests through sig-openbolt, and I would want a review from someone who knows the runtime and packaging side.

Docs

Either answer feeds OpenVoxProject/openvox-docs#566, which keeps the 5.x docs frozen beside the new 9.x docs. It also gives OpenVoxProject/openvox-docs#503, the product life-cycle page, its first concrete policy statement.

Assisted by Claude.