Foreman 3.13.0 release process

[ColeHiggins2]

Make this post a wiki (help)

Roles

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

Preparing code: 2024-12-03

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

• Make sure any release blocking issues are resolved and remove/change target version field for any open Redmine tickets assigned to the release still (next minor, unset it or reject). Look for the 3.13.0 release TODO saved query on Foreman’s issues.
• Ensure that code in git matches issues fixed in 3.13.0 in Redmine. Use the 3.13.0 release DONE saved query on Foreman’s issues. 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-12-03

Release Owner

• Make sure test_3_13_stable and smart-proxy-3.13-stable-test are green using verify_green_jobs
• Run make -C locale tx-update in foreman 3.13-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.13.0 state to Closed using close_redmine_version
• Add a new Redmine version for 3.13.1. 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-12-03

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.13 using bump_rpm_packaging
  • deb/3.13 using bump_deb_packaging
• Wait for packages to be built using wait_packaging (checks rpm/3.13 and deb/3.13). This takes a while so you can already start on the manual updates.
• Check for outstanding PRs against 3.13 packaging, and merge if possible:
  • rpm/3.13
  • deb/3.13
• 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-12-03

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.13.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.13.0 > ./guides/doc-Release_Notes/topics/foreman-3.13.0.adoc
  • Append CLI release notes taken from the hammer-cli and hammer-cli-foreman changelogs to foreman-3.13.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.13/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.13
    • Update foreman_latest_releases
• Update the docs.theforeman.org master
  • Update 3.13 as supported: sed -i '/"state":/ s/"[A-Za-z]\+",/"supported",/' web/releases/3.13.json
  • Update 3.11 as unsupported: sed -i '/"state":/ s/"[A-Za-z]\+",/"unsupported",/' web/releases/3.11.json
• Update the docs.theforeman.org 3.13 DocState as stable in attributes.adoc: sed -i '/:DocState:/ s/ .\+/ stable/' guides/common/attributes.adoc
• Update the docs.theforeman.org 3.11 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.8 and newer)
• Release pipeline will trigger foreman-plugins-3.13-deb-test-pipeline and foreman-plugins-3.13-rpm-test-pipeline. These don’t block releases but can be used to understand known issues around plugin compatibility with Foreman 3.13.
• Prepare 3.13.1 by updating the 3.13.0 release TODO and 3.13.0 release DONE saved queries on Foreman’s issues. Be sure to update both the name and individual filters.