Katello 4.7 branching process

Development Releases
1

Hello community,

We’re less than 1 month out from the targeted Foreman 3.5 branching date, and hence the Katello 4.7 branching date as well. I’ve posted the Katello 4.7 branching process below.

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
    • make -C locale tx-update in the katello directory
    • grunt i18n:compile in the katello/engines/bastion_katello directory
    • bundle exec rake plugin:gettext[katello] in the foreman directory
    • Commit the resulting files in the katello directory with a message like “i18n - pulling from tx”
    • 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

  • 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
  • Ensure stable Pulp release
  • Coordinate with installer maintainers that expected changes are completed.
  • Create PRs to Jenkins-jobs to add a mapping between the current Foreman and Katello release branches and update pipelines. See this test mapping PR example and this pipeline PR example.
  • Files to edit: testKatello.groovy, katello-pipelines.yml, and katello-rpm-pipeline.yaml.
  • 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/476.yaml matches expectations

On Branch Date

Release Owner

  • Create KATELLO-4.7 branches
  • Bump versions to 4.8-master
  • Generate and post the release procedure, if not already posted:
    • (Note that Katello uses dots instead of dashes for release candidates, e.g. 4.1.1.rc1 not 4.1.1-rc1)
    • Make sure to run ./tools.rb setup-environment first
    • Run ./tools.rb procedure release katello 4.7.0.rc1 <%= target_date %> @cintrix84 @pcreech in tool_belt
    • Post the output in Development with a “Releases” tag
  • Branch docs
    • Draft release notes in markdown (example), with these sections (and do not use personal pronouns):
      • Headline features: half a dozen important features with a few sentences description each
      • Upgrade notes: all important notices that users must be aware of before upgrading
      • Release notes: bullet point list by category of most changes, excluding bug fixes for issues introduced during the release cycle, include link to bug numbers. You can auto-generate changes using the changelog command in tool_belt (make sure to run the setup-environment command first)
      • Add contributor list on release notes page: git shortlog -s KATELLO-4.0..KATELLO-4.1
    • Create a pull request to theforeman/foreman-documentation:
      • Locate the Foreman documentation PR for the current version - example here
      • Add Katello-related content in the same file and base the PR off of the Foreman PR
    • Clone GitHub - theforeman/apidocs: API documentation for Foreman and its plugins and follow the Katello README section to update the API documentation.
  • Prepare “Katello Next” and future redmine versions
    • Rename the “Katello Next” release to Katello 4.8.0
    • Recreate the “Katello Next” release and indicate that it is a placeholder for issues belonging to the next version of Katello
    • Create the next ‘z’ release: Katello 4.7.1
    • Create the “Katello 4.7.1 TODO” custom query using the last one as a template

Release Engineer

  • Run ./tools koji configs/katello/4.7.yaml --confirm from tool_belt to create Koji tags
  • Run ./tools mash-scripts configs/katello/4.7.yaml from tool_belt to create Koji mash configs and open PR to tool_belt to commit
  • Copy mash configs to Koji scp mash_scripts/katello/4.7/*.mash root@koji.katello.org:/etc/mash/
  • Update the branch map in the mash script and deploy it to Koji scp collection-mash-split.py root@koji.katello.org:/usr/local/bin
  • Add <%= release %> to Forklift versions config
  • Add new Katello release job to foreman-infra
  • Update Katello PR pipeline with new version pipeline
2

4.7.0 rc1 release wiki:

3

@pcreech

Branching stuff that is on my end is done, when you want to get time can you do the release engineer stuff?

4

I’ve performed the release engineer’s steps and with that we can consider the branching to be complete.

1 Like
5

FWIW, the branching steps don’t include to bump packaging to “next” once git has been bumped (to 4.8 in this case).

I’ve now did that manually, but we should add that to the steps:
https://github.com/theforeman/foreman-packaging/pull/8729

1 Like
6

+1

Will create a pr to Toolbelt to update the steps

1 Like