Actions
Release Process » History » Revision 127
« Previous |
Revision 127/211
(diff)
| Next »
Dominic Cleal, 04/23/2015 04:21 AM
tag_suffix change with new version
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.
First steps¶
- 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 Releases, 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
- create public custom query with target version set, sorted by status ascending, then priority descending
- Go through targeted features in redmine and align features with our backlog
Before creating branch in git¶
- Announce beginning of bug-squashing to foreman-dev (example)
- Copy website manual content (theforeman.org repo) from previous version to this version (example)
- Change
$latest
and$next
parameters onweb
class to point to the new version numbers (seeforeman-infra/puppet/modules/web/manifests/init.pp
) - Update manual if applicable for any additional installation steps
- Draft release notes in markdown (example) using roadmap, 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 (helper vim search and replace command bellow)
- CLI release notes are taken from the hammer-cli and hammer-cli-foreman changelogs
- Link to installer changelogs and note the rough versions being used
- Check
git log
for any changes without associated bug number and add to release notes if applicable (https://gist.github.com/lzap/6520535) - Refresh kickstart, snippet and partition table templates from the community-templates repo to Foreman core
- Clone tags and create build targets in Koji using koji/copy-tags-commands.sh in foreman-packaging/rpm/develop
- foreman-1.2-rhel6 etc. as clones of nightly tags
- foreman-plugins-1.2-rhel6 etc. with inheritance from the new Foreman tags
- Untag all git/nightly builds:
for t in foreman-1.2-rhel6 foreman-1.2-nonscl-rhel6 foreman-1.2-rhel7 foreman-1.2-nonscl-rhel7 foreman-1.2-fedora19; do kkoji list-tagged $t | grep git | awk '{print $1}' | xargs kkoji untag-build $t; done
- check for non-SCL packages that might be in the SCL tags and untag them, else these will cause mash precedence issues
for t in foreman-1.2-rhel6 foreman-1.2-rhel7; do kkoji list-tagged $t --quiet | egrep "^(rubygem-|foreman)" | awk '{print $1}' | xargs kkoji untag-build $t; done
- Create mash scripts and configuration on Koji
- copy /usr/local/bin/foreman-mash-split-1.*.py to foreman-mash-split-1.2.py, update the OSes and version numbers at the bottom
- copy /etc/mash/foreman-1.*-*.mash, update the version numbers, add/remove files for OS changes
- Add new plugin tags (i.e. 1.2) to Koji plugins mash script (foreman-mash-split-plugins.py), remove old ones (keep three)
- Add version (1.2) to release_plugins_push job (note, it will be added to tests later), remove old ones (keep three)
- Clone Debian nightly repos to 1.2 using copy/freight instructions
- Add release to "Found in release" list in redmine: http://projects.theforeman.org/custom_fields/4/edit
Helper vim command to replace all (#1234)
bugs with links:
%s/(\(#\)\([0-9]\+\))/(\[\1\2]\(http:\/\/projects.theforeman.org\/issues\/\2))/g
Pre-release candidates¶
When ready to branch for release candidates.
- Make releases of installer modules, usually new minor or major versions
- Add new languages that are at a reasonable completion on Transifex to develop
- In foreman develop run
make -C locale tx-update
- In foreman, smart-proxy, foreman-installer and foreman-selinux branch develop to 1.2-stable (from this point cherry-picks into this branch only from this point using:
git cherry-pick -x SHA
) - In foreman-installer, branch 1.2-stable,
- change Puppetfile from git references to specific version ranges (e.g.
>= 1.3.1 < 1.4.0
)
- change Puppetfile from git references to specific version ranges (e.g.
- In foreman-packaging for RPMs:
- branch rpm/develop to rpm/1.2
- on rpm/1.2, in rel-eng/releasers.conf and rel-eng/tito.props, replace "nightly" with "1.2"
- on rpm/develop
- change foreman/foreman-proxy/foreman-installer/foreman-selinux version to 1.3.0, add %changelog entry
- change tag_suffix to
.fm1_3
in rel-eng/tito.props
- In foreman-packaging for debs:
- on deb/develop, update debian/*/*/changelog with entries from 1.1, commit with message "Sync 1.1.x releases into changelogs"
- branch deb/develop to deb/1.2
- on deb/develop, run
scripts/changelog.rb -v 1.3.0-1 -m "Bump changelog to 1.3.0 to match VERSION" debian/*/*/changelog
- In foreman develop commit with message "Bump version to 1.3-develop":
- change to VERSION to 1.3.0-develop
- run
extras/changelog
- In smart-proxy develop commit with message "Bump version to 1.3-develop":
- change to VERSION to 1.3.0-develop
- run
extra/changelog
- In foreman-selinux develop commit with message "Bump version to 1.3-develop":
- change to VERSION to 1.3.0-develop
- run
extras/changelog
- In foreman-installer develop commit with message "Bump version to 1.3-develop":
- change to VERSION to 1.3.0-develop
- Update foreman-dev with translations status to encourage 100% translations before release, announce string freeze date
- Change Transifex resource URL to point to the 1.2-stable branch
- Set up test_1_2_stable job on Jenkins, copy from existing stable or test_develop (don't use dots in the name, it breaks)
- Set up test_proxy_1_2_stable job on Jenkins in the same way
- Update release notes in new website manual version
- Generate a release GPG key using GPG_Keys
- publish to keyserver
- security.md on the website
- create
releases/1.2/RPM-GPG-KEY-foreman
on yum.theforeman.org - update koji's /etc/mash/foreman-1.2-*.mash with GPG key ID
For each release candidate¶
- Make patch releases of installer modules that have important changes
- Compare tagged packages in nightly vs. release koji tag and re-tag any updated dependencies that are required
- In foreman 1.2-stable run
make -C locale tx-update
- In foreman 1.2-stable commit with message "Release 1.2.0-RC1":
- change VERSION to 1.2.0-RC1
- run
extras/changelog
- In smart-proxy 1.2-stable commit with message "Release 1.2.0-RC1":
- change VERSION to 1.2.0-RC1
- run
extra/changelog
- In foreman-selinux 1.2-stable commit with message "Release 1.2.0-RC1":
- change VERSION to 1.2.0-RC1
- run extras/changelog
- In foreman-installer 1.2-stable commit with message "Release 1.2.0-RC1":
- change VERSION to 1.2.0-RC1
- Tag commits in foreman, smart-proxy, foreman-installer and foreman-selinux:
git tag -m "Release 1.2.0-RC1" 1.2.0-RC1
- Push to the project repos:
git push project && git push project 1.2.0-RC1
- Run the Jenkins Release Pipeline to create tarballs
- Verify tarballs are present on downloads.theforeman.org, download, sign and upload detached signatures
gpg --homedir gnupg/1.2 -b -u packages@theforeman.org foreman-1.2.0-RC1.tar.bz2
(requires 1.2 release GPG key generated above)
- In foreman-packaging rpm/1.2 branch, change foreman.spec, foreman-proxy.spec, foreman-selinux.spec, foreman-installer.spec:
- set version to "1.2.0", release to "0.1%{?dotalpha....", uncomment alphatag* (replace # with %), change to RC1
- change
foreman/foreman.repo
URLs from/nightly
to/releases/1.2
, change "nightly" in name to "1.2" and enable gpg checking - change
foreman/foreman-plugins.repo
URLs from/plugins/nightly
to/plugins/1.2
, change "nightly" in name to "1.2" and DO NOT enable GPG checking - update
foreman/foreman.gpg
with the release public key - in each package dir, run
spectool -g *.spec
andgit annex add *.tar.bz2
- commit with message "Release 1.2.0-RC1"
- perform RPM scratch build of each project (see RPM_Packaging)
- tag each project with
tito tag --keep-version --auto-changelog-message "Release 1.2.0-RC1"
- Debian_Packaging: Update changelog files with appropriate data
- Trigger next step of release pipeline:
release_packages
- use RPM_Packaging for the signing steps
- Update theforeman.org sections:
_includes/social.html
version number_includes/header.html
manual links
- Follow "Publishing releases" below
For final release¶
- 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
- In foreman 1.2-stable run
make -C locale tx-update
- In foreman 1.2-stable commit with message "Release 1.2.0":
- change VERSION to 1.2.0
- run
extras/changelog
- In smart-proxy 1.2-stable commit with message "Release 1.2.0":
- change VERSION to 1.2.0
- run
extra/changelog
- In foreman-selinux 1.2-stable commit with message "Release 1.2.0":
- change VERSION to 1.2.0
- run extras/changelog
- In foreman-installer 1.2-stable commit with message "Release 1.2.0":
- change VERSION to 1.2.0
- Tag commits in foreman, smart-proxy, foreman-installer and foreman-selinux:
git tag -m "Release 1.2.0" 1.2.0
- Push to the project repos:
git push project && git push project 1.2.0
- Run the Jenkins Release Pipeline to create tarballs
- Verify tarballs are present on downloads.theforeman.org, download, sign and upload detached signatures
gpg --homedir gnupg/1.2 -b -u packages@theforeman.org foreman-1.2.0.tar.bz2
(requires 1.2 release GPG key generated above)
- In foreman-packaging rpm/1.2 branch, change foreman.spec, foreman-proxy.spec, foreman-selinux.spec, foreman-installer.spec:
- set version to "1.2.0", release to "1%{?dotalpha....", comment alphatag* (replace % with #)
- in each package dir, run
spectool -g *.spec
andgit annex add *.tar.bz2
- commit with message "Release 1.2.0"
- perform RPM scratch build of each project (see RPM_Packaging)
- tag each project with
tito tag --keep-version --auto-changelog-message "Release 1.2.0"
- Debian_Packaging: Update changelog files with appropriate data
- Trigger next step of release pipeline:
release_packages
- use RPM_Packaging for the signing steps
- Update theforeman.org sections:
_includes/social.html
version number_includes/header.html
manual links_layouts/homepage.html
quickstart link_layouts/manual.html
latestversion_config.yml
quickstart link
- Merge develop branches into master (
git merge -Xtheirs --no-ff
) for: foreman, smart-proxy, foreman-installer, foreman-selinux- Skip for now, this doesn't seem to work reliably
- Follow "Publishing releases" below
Publishing releases (RCs and final)¶
- Final only: update
$stable
class parameter onweb
class to point to the new version number (seeforeman-infra/puppet/modules/web/manifests/init.pp
) - First RC: add version (1.2) to release_plugins_test job
- Send announcement e-mail to foreman-announce, CC foreman-users, set reply-to to foreman-users
- Link to announcement e-mail on IRC, Google+ and update IRC /topic
- Update Wikipedia Foreman entry at: https://en.wikipedia.org/wiki/Foreman_(software)
- Add release to "Found in release" list in redmine: http://projects.theforeman.org/custom_fields/4/edit
After final release¶
- Sync translations from Transifex into develop and update i18n
- Remove target version from all issues assigned to the current release, unless they will be fixed in a future point release
Updated by Dominic Cleal over 9 years ago · 211 revisions