Foreman 2.2 branching process

Development Releases
1

Make this post a wiki

Two weeks before branching

Installer Maintainer

Release Owner

  • Ensure headline features planned for the release have been merged or push them off to the next release.
  • Translations:

During the week before branching

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 2.2 and update version numbers mentioned in it.
    • Clean up deprecation and upgrade warnings from nightly manual.
  • Add new languages that are at a reasonable completion on Transifex to develop

Release Engineer

Branching

Release Engineer

  • Branch RPM packaging using tool_belt
    • Create configs/foreman/2.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/2.2.yaml
sed -i '/strict_keys/ s/True/False/' mash_scripts/foreman/2.2.0/foreman-plugins-2.2-*.mash
      • Open PR with new config and mash scripts for review
    • Clone tags and create build targets in Koji: bundle exec ./tools.rb koji --commit configs/foreman/2.2.yaml
    • Create a rpm/2.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

Release engineer

  • Update foreman-packaging rpm/develop to ensure nightlies build:
    • rpm/develop:
      • Update the build tag: sed -i 's/fm2_2/fm2_3/g' rel-eng/{releasers.conf,tito.props}
      • Set to version 2.3.0, reset release to 1 in packages/foreman/foreman{,-{installer,proxy,release,selinux}}/*.spec and create a changelog using obal changelog --message '- Bump version to 2.3-develop' foreman{,-{installer,proxy,release,selinux}}
    • deb/develop: scripts/changelog.rb -v 2.3.0-1 -m "Bump changelog to 2.3.0 to match VERSION" debian/*/*/changelog
  • Prepare build systems for 2.2 release:
    • foreman-packaging’s rpm/2.2
      • Update packages/foreman/foreman-release/foreman.gpg, mock/*.cfg, package_manifest.yaml, rel-eng/{releasers.conf,tito.props} and repoclosure/*.conf
    • Create mash configuration on Koji, from tool_belt checkout:
      scp mash_scripts/foreman/2.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 foreman-infra
      • Create a 2.2.groovy in pipelines/vars/foreman/ describing the operating systems the release supports
      • Add 2.2 to the version list in yaml/jobs/pipeline/foreman-release.yaml
      • Create test_2_2_stable.yaml and test_proxy_2_2_stable.yaml in yaml/jobs/
      • PR
      • Remove the oldest version to keep last 3 from the files/directories in the previous steps
  • Add 2.2 to Forklift versions config

Other systems

Release Owner

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

Just a thought: can we add concrete dates instead of next week etc? https://github.com/theforeman/tool_belt/blob/master/procedures/foreman/branch.md.erb is ERB so we can use Ruby to do some date calculation in the template.

3

PR implementing this idea – https://github.com/theforeman/tool_belt/pull/294