Foreman 3.2 branching process

Development Releases
1

Make this post a wiki

Roles

Prep Week: 2022-01-24 to 2022-01-28

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 via Foreman localization
    • Update foreman-dev with translations status to encourage 100% translations before release

Stabilization Week: 2022-01-31 to 2022-02-04

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.2 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:

  • 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.2.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.2.yaml
sed -i '/strict_keys/ s/True/False/' mash_scripts/foreman/3.2.0/foreman-plugins-3.2-*.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.2.0/*.mash root@koji.katello.org:/etc/mash/
  • Update mash script if needed - collection-mash-split.py
  • Add the new release to the JJB job definitions in jenkins-jobs
    • Create a 3.2.groovy in pipelines/vars/foreman/ describing the operating systems the release supports
    • Add 3.2 to the version list in theforeman.org/yaml/includes/foreman_versions.yaml.inc
    • Add 3.2 to the version list in centos.org/jobs/foreman-pipelines.yml
    • Create test_3_2_stable.yaml and test_proxy_3_2_stable.yaml in yaml/jobs/
  • Open PR to remove any jobs that are related to end of life versions
  • Open PR to add 3.2 to Forklift versions config. Once the PR is merged, upgrade pipelines will fail, so do not merge it before packaging has been branched.

Branching: 2022-02-10

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.2.yaml
    • Create a rpm/3.2 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: 2022-02-10

Release engineer

  • Update foreman-packaging rpm/develop to ensure nightlies build:
    • rpm/develop:
      • Update the build tag: sed -i 's/fm3_2/fm3_3/g' rel-eng/{releasers.conf,tito.props} package_manifest.yaml
      • Set to version 3.3.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.3-develop' foreman{,-{installer,proxy,release,selinux}} rubygem-hammer_cli{,_foreman}
    • deb/develop: scripts/changelog.rb -v 3.3.0-1 -m "Bump changelog to 3.3.0 to match VERSION" debian/*/*/changelog
  • Prepare build systems for 3.2 release:
    • foreman-packaging’s rpm/3.2
      • Update packages/foreman/foreman-release/foreman.gpg, mock/*.cfg, package_manifest.yaml, rel-eng/{releasers.conf,tito.props} and repoclosure/*.conf
  • Trigger the foreman-packaging-rpm-3.2 job once, so that GitHub hooks are properly set up.
  • Trigger the foreman-packaging-deb-3.2 job once, so that GitHub hooks are properly set up.

Other systems: 2022-02-10

Release Owner

  • Create release schedule page for next version (3.3) linked from Development_Resources and post planned schedule on Discourse.
  • Create Redmine versions
    • Add next version number (3.3.0) and make sure it is shared with subprojects in foreman
    • Add first patch release (3.2.1) and make sure it is shared with subprojects in foreman
  • Ensure current Foreman deprecations for the next release are removed in develop There are no deprecations of 3.2 version, so nothing to remove.

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

2

Making a list of installer PRs that must (using RFC2119 definitions for must and should) be merged before doing releases:

Things that should be merged:

I haven’t gone over puppet-puppet yet.

3

All installer modules have been released. From the installer side everything is ready to branch and release RC1.

1 Like
4

All tasks other than the last two release engineer tasks have been completed. Those last ones are waiting on a couple PRs to be merged.