Writing release notes
- Update manual if applicable for any additional installation steps
-
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
- CLI release notes are taken from the hammer-cli and hammer-cli-foreman changelogs
- Link to installer changelogs and note versions being used
- Get the apipie doc and place it in api/1.20
Preparing code
- Request Hammer CLI releases from maintainers if desired
-
Make patch releases of installer modules that have important changes
- Branch to MAJ.MIN-stable if recent changes to the module aren’t suitable for patch (x.y.z) release
- Compare tagged packages in nightly vs. release koji tag and re-tag any updated dependencies that are required
- Remove/change release field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
- List all issues targeted at the release, order by Closed date ascending and use git cherry-pick -x to cherry pick from develop to 1.20.0-RC2-stable branch
-
Clone tool_belt and run:
-
./tools.rb setup-environment configs/foreman/1.20.yaml
-
./tools.rb cherry-picks --version 1.20.0-RC2 configs/foreman/1.20.yaml
- Verify tickets in the cherry_picks_1.20.0-RC2 file are accounted for or additional cherry pick them
-
Tagging a release
-
In foreman 1.20-stable:
- Make sure test_1_20_stable is green
- run make -C locale tx-update (if Transifex has not switched to the next major release yet, usually after .2)
- run script/sync_templates.sh
- change VERSION to 1.20.0-RC2
-
Run
extras/changelog
-
Commit:
git commit -m "Release 1.20.0-RC2"
-
Tag:
git tag -s -m "Release 1.20.0-RC2" 1.20.0-RC2
-
Push:
git push --follow-tags
-
In smart-proxy 1.20-stable:
- Make sure test_proxy_1_20_stable is green
- change VERSION to 1.20.0-RC2
-
Run
extra/changelog
-
Commit:
git commit -m "Release 1.20.0-RC2"
-
Tag:
git tag -s -m "Release 1.20.0-RC2" 1.20.0-RC2
-
Push:
git push --follow-tags
-
In foreman-selinux 1.20-stable:
- change VERSION to 1.20.0-RC2
-
Run
extras/changelog
-
Commit:
git commit -m "Release 1.20.0-RC2"
-
Tag:
git tag -s -m "Release 1.20.0-RC2" 1.20.0-RC2
-
Push:
git push --follow-tags
-
In foreman-installer 1.20-stable:
- change VERSION to 1.20.0-RC2
-
Commit:
git commit -m "Release 1.20.0-RC2"
-
Tag:
git tag -s -m "Release 1.20.0-RC2" 1.20.0-RC2
-
Push:
git push --follow-tags
- Run the Jenkins Tarballs Release to create tarballs
- Verify tarballs are present on downloads.theforeman.org
- Download, sign and upload detached signatures
Note: If for some reason there was an issue with the tarballs that required uploading new tarballs, CDN cache should be invalidated so that the builders use the updated tarballs.
Packaging a release
-
In foreman-packaging rpm/1.20 branch, change foreman.spec, foreman-proxy.spec, foreman-selinux.spec, foreman-installer.spec, foreman-release.spec:
-
Set version to
1.20.0
-
Set prerelease to
RC2
-
In each package dir, remove the old tarball, run
spectool -g *.spec
andgit annex add *.tar.bz2
for dir in packages/foreman/{foreman,foreman-installer,foreman-proxy,foreman-release,foreman-selinux} ; do ( cd $dir && sed -i 's/^\(%global prerelease\) .\+/\1 RC2/' *.spec && git rm -f *.tar.bz2 && spectool -g *.spec && git annex add *.tar.bz2 ) ; done
obal changelog foreman foreman-installer foreman-proxy foreman-release foreman-selinux --message '- Release 1.20.0-RC2'
- Commit with message “Release 1.20.0-RC2”
- Submit a pull request
-
Set version to
-
Update changelog files for debs:
-
scripts/changelog.rb -v 1.20.0~rc2-1 -m "1.20.0-RC2 released" debian/*/*/changelog
- Submit a pull request
-
- Trigger next step of release pipeline: release_packages
-
Use RPM_Packaging to sign RPMs
- Download RPMs
- Sign RPMs
- Upload signatures
- Upload RPMs
- Sign “extra” RPMs
- Trigger release_mash
- Trigger release_test if mashing didn’t
- Trigger release_push_deb and release_push_rpm if testing didn’t