Actions
Release Process » History » Revision 10
« Previous |
Revision 10/211
(diff)
| Next »
Dominic Cleal, 05/20/2013 07:18 AM
foreman-installer process
Release Process¶
For each major release (i.e. not patch releases), the project selects a "release nanny" who's responsible for taking the develop branch through to release.
Please amend these lists as you see free, and as you find what works and what doesn't work.
Pre-release¶
- Select the release nanny
- Ensure RPM and Debian nightly packages are in good shape and all RPM dependencies are up to date
- Ensure Transifex project is up to date
- Decide on the version number
- If number has changed, update version number in redmine
- Add next+1 anticipated version number to redmine under Settings, sharing "With subprojects"
- Check roadmap and issue search (example)
- reassign major features to next+1 version or remove version
- assign relevant bugs to this upcoming release
- multiple bugs can be managed using checkboxes and then right clicking on the boxes for a menu
- Announce beginning of bug-squashing to foreman-dev (example)
- Copy website manual content (theforeman.org repo) from previous version to this version (example)
- Update manual if applicable for any additional installation steps
- Draft release notes in markdown (example) using roadmap, with these sections:
- 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
- Check
git log
for any changes without associated bug number and add to release notes if applicable - Request creation of tags and build targets in Koji from rel-eng (foreman-1.2-rhel6 etc.)
Pre-release candidates¶
When ready to branch for release candidates.
- In foreman, smart-proxy and foreman-install, branch develop to 1.2-stable
- cherry-picks into this branch only from this point using:
git cherry-pick -x SHA
- cherry-picks into this branch only from this point using:
- Commit change to VERSION in develop to 1.3 (next+1 version) and foreman.spec + foreman-proxy.spec to 1.3.9999 (next+1 version)
- Re-tag all dependencies in Koji to the release tag (
kkoji tag-pkg foreman-1.2-rhel6 PKG...
) - Update foreman-dev with translations status to encourage 100%25 translations before release, announce string freeze date
- Update $repo in both foreman-installer/foreman and foreman_proxy modules to "rc" (example)
For each release candidate¶
- Commit change to VERSION in 1.2-stable to 1.2.0-RC1 and foreman.spec + foreman-proxy.spec version to 1.2.0 and release to RC1
- Update version and dependency versions in all foreman-installer submodules
- Update submodules on foreman-installer's develop branch
- Tag commits in foreman, smart-proxy and foreman-installer as 1.2.0-RC1
- Perform scratch build and then tag and release real build of foreman and foreman-proxy (see RPM_Packaging)
- FIXME: update Debian build script with tag and trigger Debian build
- Build foreman-installer modules from develop (see Installer_Packaging workflow)
- Build foreman-installer RPM and Debian packages from develop (see RPM_Packaging and Debian_Packaging)
For final release
- Update version and dependency versions in all foreman-installer submodules
- Revert $repo in both foreman-installer/foreman and foreman_proxy modules to "stable" (example)
- Update submodules on foreman-installer's develop branch
- Merge foreman-installer's develop branch into master
- Build foreman-installer modules from master (see Installer_Packaging workflow)
- Build foreman-installer RPM and Debian packages from master (see RPM_Packaging and Debian_Packaging)
Updated by Dominic Cleal over 11 years ago · 10 revisions