Foreman 3.6 branching process

Make this post a wiki


Prep Week: 2023-01-31 to 2023-02-04

Installer Maintainer

Release Owner

  • Ensure headline features planned for the release have been merged or push them off to the next release.
  • Translations:
    • Update locales in foreman develop: make -C locale tx-update
    • Ask plugin authors to start extracting i18n strings and pushing the changes into develop/master git branches so Transiflex can pick it up
    • Announce string freeze date on Discourse and send announcement
    • Update foreman-dev with translations status to encourage 100% translations before release

Stabilization Week: 2023-02-07 to 2023-02-11

Release Owner

  • Announce start of stabilization week to discourse development category.
  • Request new Hammer CLI release from maintainers if needed.
  • Prepare the manual for the new version:
    • Change $next parameter on web class to point to the new version number.
    • Copy website manual content from nightly to 3.6 and update version numbers mentioned in it.
    • Update installer options section of nightly manual using the get-params script
    • Clean up deprecation and upgrade warnings from nightly manual.
  • Branch foreman-documentation git repository and update website for new release:
  • Add new languages that are at a reasonable completion on Transifex to develop

Release Engineer

  • Create new GPG key for release. See GPG_Keys if needed.
  • Publish the key by exporting the GPG key
  • Create new settings files for client, ensure it has the rights OSES list and commit it too.
  • Create configs/foreman/3.6.yaml based on the nightly and previous release. Ensure that any based_on entries are filled out and pointing to nightly version of tag.
    • Generate mash configs
      bundle exec ./tools.rb mash-scripts configs/foreman/3.6.yaml
      sed -i '/strict_keys/ s/True/False/' mash_scripts/foreman/3.6.0/foreman-plugins-3.6-*.mash
    • Open PR with new config and mash scripts for review
    • Create mash configuration on Koji, from tool_belt checkout:
      scp mash_scripts/foreman/3.6.0/*.mash
  • Update
    • Add a Katello version mapping
    • Make any changes if needed (usually happens when there are tag changes)
    • Deploy using scp
  • Open a PR with the result of jenkins-jobs branching: ./branch-foreman 3.6 KATELLO_VERSION
  • Open PR to remove any jobs that are related to end of life versions
  • Open PR to add 3.6 to Forklift versions config. Once the PR is merged, upgrade pipelines will fail, so do not merge it before packaging has been branched.

Branching: 2023-02-14

Release Engineer

  • Branch RPM packaging using tool_belt
    • Clone tags and create build targets in Koji: bundle exec ./tools.rb koji --commit configs/foreman/3.6.yaml
    • Create a rpm/3.6 branch in foreman-packaging based on rpm/develop
  • Branch Debian packaging

Release Owner

The next step should only be done after all branching, including packaging, has completed.

Preparing build systems: 2023-02-14

Release engineer

  • Update foreman-packaging rpm/develop to ensure nightlies build:
    • rpm/develop:
      • Update the build tag: sed -i 's/fm3_6/fm3_7/g' package_manifest.yaml
      • Set to version 3.7.0, reset release to 1 in packages/foreman/foreman{,-{installer,proxy,release,selinux}}/*.spec and packages/foreman/rubygem-hammer_cli{,_foreman}/*.spec. Then create a changelog using obal changelog --message '- Bump version to 3.7-develop' foreman{,-{installer,proxy,release,selinux}} rubygem-hammer_cli{,_foreman}
    • deb/develop: scripts/changelog.rb -v 3.7.0-1 -m "Bump changelog to 3.7.0 to match VERSION" debian/*/*/changelog
  • Prepare build systems for 3.6 release:
    • foreman-packaging’s rpm/3.6
      • Update packages/foreman/foreman-release/foreman.gpg, mock/*.cfg, package_manifest.yaml and repoclosure/*.conf
    • foreman-packaging’s deb/3.6
  • Trigger the foreman-packaging-rpm-3.6 job once, so that GitHub hooks are properly set up.
  • Trigger the foreman-packaging-deb-3.6 job once, so that GitHub hooks are properly set up.

Other systems: 2023-02-14

Release Owner

  • Create release schedule page for next version (3.7) linked from Development_Resources and post planned schedule on Discourse.
  • Create Redmine versions
    • Add next version number (3.7.0) and make sure it is shared with subprojects in foreman
    • Add first patch release (3.6.1) and make sure it is shared with subprojects in foreman
  • Ensure current Foreman deprecations for the next release are removed in develop

This was based on the wiki procedure and sometimes has a bit more info.

@ofedoren I have branched Hammer CLI, but didn’t do the version bump yet since I noticed that X.Y.0 is always tagged in master rather than the stable branch. Do you want to continue that trend?

Please, don’t do that, it’s always better to just ping me, I’ll release both gems. If you’re not doing it manually, but via script, you could integrate logic from [1] into that for hammer branching process.

In hammer we have decent Jupyter notebook [1], which has automated steps for a human to re-check. It allows to do the same process for both repos each time. I’m quite used to that and I personally would like to leave it as is.

[1] - hammer-cli/gem_release.ipynb at master · theforeman/hammer-cli · GitHub

The 3.7 packaging bump has issues with CentOS Stream 9, but I’m not quite sure how to get that unstuck in Koji: