Creating a `Release Update`

The Release Update Process

A Release Update involves creating a new branch, v#{x}R#{x+1}, from the current main or latest patch release branch. The saf generate delta workflow is then run, which updates the metadata of the controls, inspec.yml, README.md, and other profile elements, while preserving the describe and ruby code logic. This workflow is detailed in the Inspec Delta section. After the initial commit of the new release branch, follow these steps to keep your work organized:

1. Track Control IDs: Create a table of all new control ids in the updated benchmark. This can be in CSV, Markdown Table, or in the PR overview information section. This helps track completed and pending work. PRs off the v#{x}r#{x+1} can also be linked in the table, especially if using a micro vs massive PR approach.
2. Ensure Consistency: Add 'check box columns' to your tracking table to ensure each requirement of the updated Benchmark receives the same level of scrutiny.
3. Update CI/CD Process: Update elements such as the hardening content (ansible, puppet, chef, hardened docker images, hardened vagrant boxes) to meet new requirements. Ensure the CI/CD process still functions with the updated elements, preferably on the PR as well.
4. Update Labels: Update titles and other labels to reflect the updated release number of the Benchmark.
5. Commit Changes: Commit these changes to your release branch, ensuring your CI/CD process exits cleanly.
6. Follow Patch Update Workflow: With the above in place, follow the 'Patch Update' process, but expect a larger number of requirements to revalidate or update.
7. Identify Potential Code Changes: Controls with changes to the check text or fix text are likely to require inspec code changes. If the check text and fix text of a control remain unchanged, it's likely only a cosmetic update, with no change in the security requirement or validation code.