Foreman 3.12.0 release process

[ColeHiggins2]

Make this post a wiki (help)

Roles

• Release Owner: @ColeHiggins2
• Release Engineer: @pcreech
• Installer Maintainer: @

Preparing code: 2024-09-17

Installer Maintainer

• Make patch releases of installer modules that have important changes
  • Branch to MAJ.MIN-stable if recent changes to the module aren’t suitable for patch (x.y.z) release

Release Owner

• Remove/change target version field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
• Ensure that code in git matches issues fixed in 3.12.0 in redmine. issues can be used to generate a comparison between the two.
• Check for open pull requests in Foreman, smart-proxy, foreman-installer and foreman-selinux

Tagging a release: 2024-09-17

Release Owner

• Make sure test_3_12_stable and smart-proxy-3.12-stable-test are green using verify_green_jobs
• Run make -C locale tx-update in foreman 3.12-stable
• Update release version similar to here
• Tag the projects
  • Create tags using tag_project
  • Push tags using tag_push
• Run the Jenkins Tarballs Release using release_tarballs to create tarballs
• Change Redmine version 3.12.0 state to Closed using close_redmine_version
• Add a new Redmine version for the next minor, unless the series is EOL. Be sure the version is set to sharing with subprojects.

Release Engineer

• Sign Tarballs
  • download_tarballs
  • inspect_tarballs
  • Sign and upload detached signatures using sign_tarballs

Note: If for some reason there was an issue with the tarballs that required uploading new tarballs, CDN cache should be invalidated so that the builders use the updated tarballs.

Packaging a release: 2024-09-17

Note it is considered good practice to release on a day when the next day is a working day. This means no releases on Fridays or on the day before a holiday.

Release Engineer

Background documentation

• Update foreman-packaging branches
  • rpm/3.12 using bump_rpm_packaging
  • deb/3.12 using bump_deb_packaging
• Wait for packages to be built using wait_packaging (checks rpm/3.12 and deb/3.12). This takes a while so you can already start on the manual updates.
• Check for outstanding PRs against 3.12 packaging, and merge if possible:
  • rpm/3.12
  • deb/3.12
• Sign the RPMs in the release
  • generate_stage_repository
  • sign_stage_rpms
  • upload_stage_rpms
• Sign RPMs for client repos (call scripts with PROJECT=client)
  • generate_stage_repository
  • sign_stage_rpms
  • upload_stage_rpms
• Kick off the release pipeline by calling release_pipeline
• Kick off the client pipeline by calling PROJECT=client ./release_pipeline
• Kick off the plugins pipeline by calling plugins_pipeline

Manual updates: 2024-09-17

Release Owner

• Update manual if applicable for any additional installation steps
• Update the website’s release notes section in the manual
  • Using the release notes script: ./scripts/release_notes.rb foreman 3.12.0
  • Append CLI release notes taken from the hammer-cli and hammer-cli-foreman changelogs, in theforeman.org.
  • Headline features: half a dozen important features with a few sentences description each
  • Upgrade warnings: all important notices that users must be aware of before upgrading
  • Deprecations: anything that will be removed in a future release
  • Submit this as a PR
• Update docs.theforeman.org
  • Using redmine_release_notes script (see README as well): ./guides/doc-Release_Notes/redmine_release_notes foreman 3.12.0 > ./guides/doc-Release_Notes/topics/foreman-3.12.0.adoc
  • Append CLI release notes taken from the hammer-cli and hammer-cli-foreman changelogs to foreman-3.12.0.adoc.
  • Make sure foreman-contributors.adoc is updated
  • Make sure headline features, upgrade warnings and deprecations are in sync with the website
  • Submit this as a PR
• Update the apipie docs and place those in the foreman/3.12/apidoc directory if any changes were made to the API

After the packages have been released

Release Owner

• Update theforeman.org
  • Update installer options section using the get-params script (Note: this step can only be done after packages are released)
  • Update _config.yml
    • Update the foreman_version to 3.12
    • Update foreman_latest_releases
  • Update web/content/index.adoc and web/content/js/versions.js to declare 3.12 as stable and 3.10 as unsupported
• Update the docs.theforeman.org master
  • Update 3.12 as supported: sed -i '/"state":/ s/"[A-Za-z]\+",/"supported",/' web/releases/3.12.json
  • Update 3.10 as unsupported: sed -i '/"state":/ s/"[A-Za-z]\+",/"unsupported",/' web/releases/3.10.json
• Update the docs.theforeman.org 3.12 DocState as stable in attributes.adoc: sed -i '/:DocState:/ s/ .\+/ stable/' guides/common/attributes.adoc
• Update the docs.theforeman.org 3.10 DocState as unsupported in attributes.adoc: sed -i '/:DocState:/ s/ .\+/ unsupported/' guides/common/attributes.adoc
• Announce the release on Discourse using release_announcement
• Update the topic in #theforeman channel on Matrix
• Share the release announcement on Twitter
• Update stable_release version in foreman-infra
• Create an issue in foreman-infra to archive old Debian releases (keeping 3.7 and newer)
• Release pipeline will trigger foreman-plugins-3.12-deb-test-pipeline and foreman-plugins-3.12-rpm-test-pipeline. These don’t block releases but can be used to understand known issues around plugin compatibility with Foreman 3.12.