Foreman 3.6 branching process

Development Releases
1

Make this post a wiki

Roles

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 root@koji.katello.org:/etc/mash/
  • Update collection-mash-split.py
    • Add a Katello version mapping
    • Make any changes if needed (usually happens when there are tag changes)
    • Deploy using scp collection-mash-split.py root@koji.katello.org:/usr/local/bin
  • 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.

2

@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?

3

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

4

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