Make this post a wiki (help)
Roles
- Release Owner: @Griffin-Sullivan
- Release Engineer: @zhunting
- Installer Maintainer: @ekohl
Prep Week: 2023-11-07 to 2023-11-11
Installer Maintainer
- Make releases of installer modules
- Tier 0 (no dependencies)
- Tier 1 (Dependencies on Tier 0)
- Tier 2 (Dependencies on Tier 1)
Release Owner
- Ensure headline features planned for the release have been merged or push them off to the next release.
- Translations:
- Update locales in foreman develop:
make -C locale tx-update - Ask plugin authors to start extracting i18n strings and pushing the changes into develop/master git branches so Transiflex can pick it up
- Announce string freeze date on Discourse and send announcement
- Update foreman-dev with translations status (click on Report) to encourage 100% translations before release
- Update locales in foreman develop:
Stabilization Week: 2023-11-14 to 2023-11-18
Release Owner
- Announce start of stabilization week to discourse development category.
- Request new Hammer CLI release from maintainers if needed.
- Prepare the manual for the new version:
- Change
$nextparameter on web class to point to the new version number. - Copy website manual content from nightly to 3.9 and update version numbers mentioned in it.
- Update installer options section of nightly manual using the get-params script
- Clean up deprecation and upgrade warnings from nightly manual for in both foreman.adoc and katello.adoc.
- Change
- Add new languages that are at a reasonable completion on Transifex to develop
Release Engineer
- Create new GPG key for release. See GPG_Keys if needed.
- generate_gpg
- export_gpg_private to back up
- sign_gpg
- upload_gpg
- Publish the key
- Use export_gpg_public to show the GPG key and update the website’s security.md and create a file in static/keys
- Use upload_yum_gpg to create releases/3.9/RPM-GPG-KEY-foreman on yum.theforeman.org
- Commit the settings file to the
theforeman-rel-engrepository
- Create new settings files for client, ensure it has the rights
OSESlist and commit it too. - Open a PR with the result of jenkins-jobs branching:
./branch-foreman 3.9 KATELLO_VERSION - Open PR to remove any jobs that are related to end of life versions
- Open PR to add 3.9 to Forklift versions config. Once the PR is merged, upgrade pipelines will fail, so do not merge it before packaging has been branched. Forklift PR
Branching: 2023-11-21
Release Engineer
- Branch RPM packaging using tool_belt
- Create a
rpm/3.9branch in foreman-packaging based onrpm/develop
- Create a
- Branch RPM packaging
- Create a
rpm/3.9branch in foreman-packaging based onrpm/develop:git checkout rpm/develop && git pull && git checkout -b rpm/3.9 - Update
foreman_versioninpackage_manifest.yamlon therpm/3.9branch:sed -i '/foreman_version:/ s/nightly/3.9/' package_manifest.yaml - Update
katello_versioninpackage_manifest.yamlon therpm/3.9branch: `sed -i ‘/katello_version:/ s/nightly/KATELLO_VERSION_HERE/’ package_manifest.yaml - Create release repositories in Copr by forking nightly repositories
obal copr-project copr_projectson therpm/3.9branch
- Create a
- Branch Debian packaging
- Clone Debian nightly repos to 3.9 using copy/freight instructions
- Create a
deb/3.9branch in foreman-packaging based ondeb/develop
Release Owner
- Create 3.9-stable branches using branch_project
- Push 3.9-stable branches using branch_push
- Branch foreman-documentation git repository and update website for new release by following the README instructions
- Ask Hammer maintainer to branch hammer-cli and hammer-cli-foreman
The next step should only be done after all branching, including packaging, has completed.
- Bump versions to 3.10-develop using develop_branch_bump
- Push version bumps to 3.10-develop using develop_branch_push
- Ask Hammer maintainer to bump hammer-cli and hammer-cli-foreman
Preparing build systems: 2023-11-21
Release engineer
- Merge the earlier created jenkins-jobs PR that creates the release pipelines
- Update foreman-packaging rpm/develop to ensure nightlies build:
- rpm/develop:
- Update the build tag:
sed -i 's/fm3_9/fm3_10/g' package_manifest.yaml - Set to version
3.10.0, reset release to1inpackages/foreman/foreman{,-{installer,proxy,release,selinux}}/*.specandpackages/foreman/rubygem-hammer_cli{,_foreman}/*.spec. Then create a changelog usingobal changelog --message '- Bump version to 3.10-develop' foreman{,-{installer,proxy,release,selinux}} rubygem-hammer_cli{,_foreman}
- Update the build tag:
- deb/develop:
scripts/changelog.rb -v 3.10.0-1 -m "Bump changelog to 3.10.0 to match VERSION" debian/*/*/changelog
- rpm/develop:
- Prepare build systems for 3.9 release:
- foreman-packaging’s rpm/3.9
- Update
packages/foreman/foreman-release/foreman.gpg,mock/*.cfg,package_manifest.yamlandrepoclosure/*.conf
- Update
- foreman-packaging’s deb/3.9
- Update
debian/*/foreman-release/theforeman-archive-keyring.ascfrom https://deb.theforeman.org/foreman.asc, you will only see changes if the key was recently updated.
- Update
- foreman-packaging’s rpm/3.9
- Trigger the
foreman-packaging-rpm-3.9job once, so that GitHub hooks are properly set up. - Trigger the
foreman-packaging-deb-3.9job once, so that GitHub hooks are properly set up.
Other systems: 2023-11-21
Release Owner
- Generate and post the release procedure, if not already posted:
- Use procedure_release: `PROJECT=foreman VERSION=3.9 ./procedure_release “2023-11-21” “@Griffin-Sullivan” “@ekohl”
- Post the output in Development/Releases using
Foreman 3.9.0-rc1 release process
- Create the 3.9.0-rc release procedure in Development/Releases:
PROJECT=foreman VERSION=3.9 ./procedure_release 2023-11-21 '@Griffin-Sullivan' '@ekohl' | wl-copy - Create a
Foreman 3.10 Schedule and Planningpost on Development/Releases using schedule:./schedule 2023-11-22(make sure there are no conflicts with other important dates) - Create Redmine version 3.10.0 and make sure it is shared with subprojects in foreman
- Ensure current Foreman deprecations for the next release are removed in develop
This was based on the wiki procedure and sometimes has a bit more info.