Katello 4.11 branching process

Development Releases
1

Make this post a wiki (help)

Roles

One Month Prior to Branch Date

Release Owner

  • Start attending upstream release sync meetings and giving updates
  • Announce upcoming branching to Discourse development category a month before
  • Update Katello Transifex translations:
    • Create a Transifex account and join the Foreman team
    • Spin up a Foreman and Katello installation
    • Configure the Transifex client
    • Install grunt
    • grunt i18n:extract in the katello/engines/bastion_katello directory
    • tx pull --minimum-perc 50 --all in the katello directory
    • make -C locale tx-pull in the katello directory
    • grunt i18n:compile in the katello/engines/bastion_katello directory
    • bundle exec rake plugin:gettext[katello] in the foreman directory
    • bundle exec rake plugin:po_to_json[katello] in the foreman directory
    • make -C commit-translation-files in the katello directory
    • Add any uncommitted translation files and open a PR to Katello (no Redmine issue needed)

Three Weeks Prior to Branch Date

Release Owner

  • Ensure that issues requiring installer changes are merged

Two Weeks Prior to Branch Date

Release Owner

  • Commit the settings file to the theforeman-rel-eng repository. See an example here
  • Add tool_belt config for new release:
    • Create a new yaml file using the nightly Katello config as a template: tool_belt configs
    • Manually update the following sections:
      • releases: update to current release. Move the previous ‘current’ release to prior_releases below.
      • prior_releases: Remove the oldest prior_release (check with that release owner first to see if there’s a reason it should stay)
      • mash_scripts: update Katello version number in all values
      • repos: Update branch names to current versions, including any new releases that need to happen
      • ignores: Delete all items from this list and start fresh (this will be used for cherry-picks later)
      • gpg-key: When it becomes available, get the new Foreman GPG key for the corresponding Foreman version (example here and put the last 8 characters here
      • tags: update Katello version number in all values. Check the nightly config to see if any tags/repos need to be updated
    • Open a PR to tool_belt with the new config file
  • Coordinate with installer maintainers that expected changes are completed.
  • Review the Foreman schedule and planning (example) and note the date of the first scheduled release candidate.

Release Engineer

  • Ensure tool_belt config is merged and output from ./tools.rb koji configs/katello/4.11.yaml matches expectations

On Branch Date

Release Owner

  • Create the KATELLO-4.11 branch using branch_project
  • Push the KATELLO-4.11 branch using branch_push
  • Bump versions to 4.12-master using develop_branch_bump
  • Push version bumps to 4.12-master using develop_branch_push
  • Bump Katello related packages to their next versions
  • Generate and post the release procedure, if not already posted:
  • Prepare “Katello Next” and future redmine versions
    • Rename the “Katello Next” release to Katello 4.12.0
    • Recreate the “Katello Next” release and indicate that it is a placeholder for issues belonging to the next version of Katello
    • Create the “Katello 4.11.1 TODO” custom query using the last one as a template

Release Engineer

  • Run ./tools.rb koji configs/katello/4.11.yaml --confirm from tool_belt to create Koji tags
  • Run ./tools.rb mash-scripts configs/katello/4.11.yaml from tool_belt to create Koji mash configs and open PR to tool_belt to commit
  • Copy mash configs to Koji using deploy_mash_configs
2

The release engineer last section is not needed anymore when we use copr.

@theforeman/katello-4.11-staging Copr is the new place

1 Like