Katello 4.14.1 release procedure

Development Releases
1

This procedure was generated from procedures/katello/release.md.erb at 27e3c67169eabd4634e60d4710b4dc5e185df2fd

Make this post a wiki (help)

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.14.yaml)

  • 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.14.yaml
    • Run ./tools.rb setup-environment configs/katello/4.14.yaml
    • Run GITHUB_ACCESS_TOKEN=<secret> ./tools.rb cherry-picks --version 4.14.1 configs/katello/4.14.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.14.1 file are accounted for, or additionally cherry-pick them. Recommended: Do this in tool_belt’s checkout of Katello, in repos/katello/4.14.1/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.14.yaml

  • Change Redmine version 4.14.1 state to Closed using close_redmine_version: PROJECT=katello VERSION=4.14 ./close_redmine_version and enter your Redmine API Key when prompted.

  • Check for outdated deprecation warnings in the current and next release with ./tools check-deprecation-warnings configs/katello/4.14.yaml. Follow the instructions in the output of the command. Don’t forget to create any Redmine issues needed!

  • Update the 3.12 branch in foreman-documentation

    • Ensure release notes are correct
      • Headline features: important features with a few sentences description each
      • Upgrade notes: all important notices that users must be aware of before upgrading
      • Deprecations: features that will be removed or changed in a future version
    • Using redmine_release_notes (see README as well): ./guides/doc-Release_Notes/redmine_release_notes katello 4.14.1 > ./guides/doc-Release_Notes/topics/katello-4.14.1.adoc
    • Add topics/katello-4.14.1.adoc to guides/doc-Release_Notes/master.adoc: sed '/x.y.z releases here/a include::topics/katello-4.14.1.adoc[leveloffset=+1]' master.adoc
    • Make sure katello-contributors.adoc is updated
    • Submit this as a PR

  • Open a PR (or use cherry-pick PR) against the release branch which updates lib/katello/version.rb to 4.14.1:

    • git pull to make sure you have the latest changes
    • sed '/VERSION/ s/".\+"/"4.14.1"/' lib/katello/version.rb
    • Update/add the CHANGELOG.md file: GITHUB_ACCESS_TOKEN=<secret> ./tools changelog --version 4.14.1 configs/katello/4.14.yaml
    • Commit: git commit -m "Release 4.14.1"
    • 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):

    • Create upstream remote: git remote add upstream https://github.com/Katello/katello.git
    • Fetch upstream remote: git fetch upstream
    • Checkout upstream release branch: git checkout upstream/KATELLO-4.14
    • Tag: git tag -s -m "Release 4.14.1" 4.14.1
    • Push: git push --follow-tags (Must be pushed directly to the release branch, as pull request merges will not preserve tags.)
    • Generate .mo translation files: make -C locale all-mo in the katello directory
    • Generate source gem: gem build katello.gemspec
    • Ensure you have a working login and password at rubygems.org
    • Push gem: gem push katello-4.14.1.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

  • Confirm response that the build succeeded (or if necessary, do more cherry-picks and version bumps repeating the steps above)
  • Test the install and upgrade documentation for both the Katello server and smart proxy
  • Post a release announcement
2

This is a 404

1 Like
3

Found the correct link, will update it for 4.14.1 and also fix the procedure to have the right url

foreman-documentation/guides/doc-Release_Notes/topics/katello-4.14.0.adoc at 3.12 · theforeman/foreman-documentation

1 Like
4

I see in that same folder foreman-documentation/guides/doc-Release_Notes/topics/katello.adoc at 3.12 · theforeman/foreman-documentation · GitHub

That would be the release notes, right? seems like the other one is the changelog.

5

Yeah you are right, I will get the procedure updated to use the release notes, not the changelog

6

Raised a PR to fix the issue - Fix 404 in release notes for katello release procedure by chris1984 · Pull Request #439 · theforeman/theforeman-rel-eng

1 Like