This procedure was generated from procedures/katello/release.md.erb at c3b2de83af63f4fe43361b3b36b3177fccbf6759
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 ofconfigs/katello/4.12.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.12.yaml - Run
./tools.rb setup-environment configs/katello/4.12.yaml
- Run
GITHUB_ACCESS_TOKEN=<secret> ./tools.rb cherry-picks --version 4.12.1 configs/katello/4.12.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.12.1 file are accounted for, or additionally cherry-pick them. Recommended: Do this in tool_belt’s checkout of Katello, inrepos/katello/4.12.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 oftool_belt
inconfigs/katello/4.12.yaml
- If any minor versions of Katello have been added to Redmine since the last cherry-pick, make sure to include them in
-
Change Redmine version 4.12.1 state to Closed using close_redmine_version:
PROJECT=katello VERSION=4.12 ./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.12.yaml
. Follow the instructions in the output of the command. Don’t forget to create any Redmine issues needed! -
Update the
3.10
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.12.1 > ./guides/doc-Release_Notes/topics/katello-4.12.1.adoc
- Add
topics/katello-4.12.1.adoc
toguides/doc-Release_Notes/master.adoc
:sed '/x.y.z releases here/a include::topics/katello-4.12.1.adoc[leveloffset=+1]' master.adoc
- Make sure katello-contributors.adoc is updated
- Submit this as a PR
- Ensure release notes are correct
-
Open a PR (or use cherry-pick PR) against the release branch which updates
lib/katello/version.rb
to 4.12.1:-
git pull
to make sure you have the latest changes -
sed '/VERSION/ s/".\+"/"4.12.1"/' lib/katello/version.rb
- Update/add the CHANGELOG.md file:
GITHUB_ACCESS_TOKEN=<secret> ./tools changelog --version 4.12.1 configs/katello/4.12.yaml
- Commit:
git commit -m "Release 4.12.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.12
- Tag:
git tag -s -m "Release 4.12.1" 4.12.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.12.1.gem
- Create upstream remote:
-
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
- Wait for Foreman 3.10.0 GA to be packaged and built before proceeding
- Update release version similar to here
- Update
katello
,katello-repos
andrubygem-katello
- Use bump_rpm_packaging:
PROJECT=katello VERSION=4.12 ./bump_rpm_packaging
- Use bump_rpm_packaging:
- Merge packaging PR once job is green
- Use wait_packaging to wait for Jenkins to build the packages
- Sign the RPMs in the release
- Use release_pipeline to kick off the release pipeline
Once release is out
Release Owner
- Wait for Foreman 3.10.0 GA to be announced before proceeding
- 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
- Create and upload release specific developer stable box
- Remove references to the oldest Katello version from testKatello.groovy and katello-pipelines.yml.