Katello 4.3.0 RC release process

Roles

When Ready to Release

Release Owner

  • Request Hammer CLI Katello release from maintainers

  • Request Virt Who Configure release from maintainers

  • Request any other releases as needed from the release owners (consult the :repos: section of configs/katello/4.3.yaml)

  • Change Redmine version 4.3.0 state to Closed

  • Do Cherry-picks: Clone tool_belt

    • If any minor versions of Katello have been added to Redmine since the last cherry-pick, make sure to include them in prior_releases in configs/katello/4.3.yaml
    • Run ./tools.rb setup-environment configs/katello/4.3.yaml
    • Run ./tools.rb cherry-picks --version 4.3.0 configs/katello/4.3.yaml
    • Open a PR in Katello release branch. Make sure the PR name starts with [CP] to prevent our automations from adding it to Redmine issues.
    • Using git cherry-pick -x as needed, verify tickets in the cherry_picks_4.3.0 file are accounted for, or additionally cherry-pick them. Recommended: Do this in tool_belt’s checkout of Katello, in repos/katello/4.3.0/katello. This way when you run cherry-picks again, tool_belt will be aware of any picks already completed.
    • For any cherry-picks that are not needed (including Redmine trackers) you can add them to the :ignores: section of tool_belt in configs/katello/4.3.yaml
  • Check for outdated deprecation warnings in the current and next release with ./tools check-deprecation-warnings configs/katello/4.3.yaml. Follow the instructions in the output of the command. Don’t forget to create any Redmine issues needed!

  • Bump version:

    • Open a PR (or use cherry-pick PR) against the release branch which updates lib/katello/version.rb to 4.3.0
    • git pull to make sure you have the latest changes
    • Commit: git commit -m "Release 4.3.0"
    • Ensure that the commit above is the last commit and there are no commits after it. This is the commit that will get tagged. (Rearrange commits with git rebase -i if needed.)
  • Once the PR is merged, perform the following in the Katello release branch (the real one, not your fork):

    • Tag: git tag -s -m "Release 4.3.0" 4.3.0
    • Push: git push --follow-tags (Must be pushed directly to the release branch, as pull request merges will not preserve tags.)
    • Generate source gem: gem build katello.gemspec
    • Ensure you have a working login and password at rubygems.org
    • Push gem: gem push katello-4.3.0.gem
  • Inform the delivery team that the gem is published

Once Source is Available

Note it is considered good practice to release on a day when the next day is a working day. This means no releases on Fridays or on the day before a holiday.

Release Engineer

Once release is out

Release Owner

1 Like

after a few bumps, 4.3.0 rc1 RPMs are built and up on yum.theforeman.org

@cintrix84 please finish off the announcement and stuff

1 Like

Hi,

Has the release of 4.3.0 moved forwards? I can see RC4 packages in the repo, but no announcement of RC4 in the Release Announcements. Looking forward to taking Katello 4.3 out for a spin.

P.S. Also noticing that the Foreman 3.1 install docs point to the nightly repos. Does this need updating?

https://docs.theforeman.org/3.1/Installing_Server_on_Red_Hat/index-foreman-el.html#configuring-repositories_foreman

1 Like

@Duncan_Innes

Hi,

We are getting ready to release 4.3 GA, once this passes:

[CP] 4.3 GA and cherrypicks by chris1984 · Pull Request #9865 · Katello/katello (github.com)

Then everything will be updated.

1 Like

OK - thanks.

Shouldn’t the docs be updated already though? Pointing at Nightly repos will fetch Foreman 3.2 and Katello 4.4. Seems to me that the Docs should point to the release repos as soon as the RC packages are in there.

docs updates are in update docs for 3.1 to be stable and refer to 3.1 repos by evgeni · Pull Request #934 · theforeman/foreman-documentation · GitHub

1 Like