Project

General

Profile

Actions
History

Development Resources »

Release Process » History » Revision 152

« Previous | Revision 152/211 (diff) | Next »
Dominic Cleal, 02/23/2016 06:12 AM
redmine releases

Release Process

For each major release (i.e. not patch releases), the project selects a release manager 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

  1. Select the release manager
  2. Ensure RPM and Debian nightly packages are in good shape and all RPM dependencies are up to date
  3. Ensure Transifex project is up to date
  4. Decide on the version number
  5. If number has changed, update version number in redmine
  6. Add next+1 anticipated version number to redmine under Releases, sharing "With subprojects"

Near-end of development phase

  1. Announce beginning of bug-squashing to foreman-dev (example)
  2. Copy website manual content (theforeman.org repo) from previous version to this version (example)
    • add version number to documentation.md dropdown menu
  3. Change $latest and $next parameters on web class to point to the new version numbers (see foreman-infra/puppet/modules/web/manifests/init.pp)
  4. Update manual if applicable for any additional installation steps
  5. Draft release notes in markdown (example) using roadmap, with these sections (and do not use personal pronouns):
    1. Headline features: half a dozen important features with a few sentences description each
    2. Upgrade notes: all important notices that users must be aware of before upgrading
    3. 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)
    4. CLI release notes are taken from the hammer-cli and hammer-cli-foreman changelogs
    5. Link to installer changelogs and note the rough versions being used
  6. Check git log for any changes without associated bug number and add to release notes if applicable (https://gist.github.com/lzap/6520535)
  7. Refresh unattended templates from the community-templates to Foreman core, by running script/sync_templates.sh
  8. Create a new branch in community-templates for upcoming Foreman release (e.g. 1.2-stable)
  9. 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
  10. 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-fedora21; do kkoji list-tagged $t | grep git | awk '{print $1}' | xargs kkoji untag-build $t; done
  11. 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 and foreman-plugins-1.*-*.mash, update the version numbers, add/remove files for OS changes, set GPG key ID and ensure strict_keys=True
  12. Add new plugin tags (i.e. 1.2) to Koji plugins mash script (foreman-mash-split-plugins.py), remove old ones (keep three)
  13. Add version (1.2) to these jobs, remove old ones (keep three)
    1. release_plugins_push (note, it will be added to tests later)
    2. packaging_plugin_retag
    3. packaging_retag
  14. Clone Debian nightly repos to 1.2 using copy/freight instructions
  15. 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

Branching for series

When ready to branch for release candidates.

  1. Make releases of installer modules, usually new minor or major versions
  2. Add new languages that are at a reasonable completion on Transifex to develop
  3. In foreman develop run make -C locale tx-update
  4. 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)
  5. In foreman-installer, branch 1.2-stable,
    1. change Puppetfile from git references to specific version ranges (e.g. >= 1.3.1 < 1.4.0)
  6. In foreman-packaging for RPMs:
    1. branch rpm/develop to rpm/1.2
    2. on rpm/1.2
      1. in rel-eng/releasers.conf and rel-eng/tito.props, replace "nightly" with "1.2"
      2. change foreman/foreman.repo URLs from /nightly to /releases/1.2, change "nightly" in name to "1.2" and enable gpg checking
      3. 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
      4. update foreman/foreman.gpg with the release public key
    3. on rpm/develop
      1. change foreman/foreman-proxy/foreman-installer/foreman-selinux version to 1.3.0, add %changelog entry
      2. change tag_suffix to .fm1_3 in rel-eng/tito.props, and rel-eng/releasers.conf
  7. In foreman-packaging for debs:
    1. on deb/develop, update debian/*/*/changelog with entries from 1.1, commit with message "Sync 1.1.x releases into changelogs"
    2. branch deb/develop to deb/1.2
    3. on deb/develop, run scripts/changelog.rb -v 1.3.0-1 -m "Bump changelog to 1.3.0 to match VERSION" debian/*/*/changelog
  8. In foreman develop commit with message "Bump version to 1.3-develop":
    1. change to VERSION to 1.3.0-develop
    2. run extras/changelog
  9. In smart-proxy develop commit with message "Bump version to 1.3-develop":
    1. change to VERSION to 1.3.0-develop
    2. run extra/changelog
  10. In foreman-selinux develop commit with message "Bump version to 1.3-develop":
    1. change to VERSION to 1.3.0-develop
    2. run extras/changelog
  11. In foreman-installer develop commit with message "Bump version to 1.3-develop":
    1. change to VERSION to 1.3.0-develop
  12. Update foreman-dev with translations status to encourage 100% translations before release, announce string freeze date
  13. Change Transifex resource URL to point to the 1.2-stable branch
  14. 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)
  15. Set up test_proxy_1_2_stable job on Jenkins in the same way
  16. Update release notes in new website manual version

Preparing a release

Version numbers for release candidates start with "1.2.0-RC1" (always hyphenated). The first release after RC would be "1.2.0". Change examples below as appropriate.

  1. 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
  2. Compare tagged packages in nightly vs. release koji tag and re-tag any updated dependencies that are required
  3. Add a new Redmine release for the next minor, unless the series is EOL
  4. Remove/change release field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
  5. Change Redmine release state to Closed
  6. 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.2-stable branch
  7. Clone tool_belt (foreman branch) and run:
    1. ./tools.rb setup-environment configs/foreman_12.yaml
    2. ./tools.rb cherry-picks --version 1.2.0 configs/foreman_12.yaml
    3. Verify tickets in the cherry_picks_1.2.0 file are accounted for or additional cherry pick them

Tagging a release

  1. In foreman 1.2-stable run:
    1. make -C locale tx-update
    2. script/sync_templates.sh
  2. In foreman 1.2-stable commit with message "Release 1.2.0":
    1. change VERSION to 1.2.0
    2. run extras/changelog
  3. In smart-proxy 1.2-stable commit with message "Release 1.2.0":
    1. change VERSION to 1.2.0
    2. run extra/changelog
  4. In foreman-selinux 1.2-stable commit with message "Release 1.2.0":
    1. change VERSION to 1.2.0
    2. run extras/changelog
  5. In foreman-installer 1.2-stable commit with message "Release 1.2.0":
    1. change VERSION to 1.2.0
  6. Tag commits in foreman, smart-proxy, foreman-installer and foreman-selinux: git tag -m "Release 1.2.0" 1.2.0
  7. Push to the project repos: git push project && git push project 1.2.0
  8. Run the Jenkins Release Pipeline to create tarballs
  9. Verify tarballs are present on downloads.theforeman.org, download, sign and upload detached signatures
    1. gpg --homedir gnupg/1.2 -b -u packages@theforeman.org foreman-1.2.0.tar.bz2 (requires 1.2 release GPG key generated above)

Packaging a release

  1. In foreman-packaging rpm/1.2 branch, change foreman.spec, foreman-proxy.spec, foreman-selinux.spec, foreman-installer.spec:
    1. set version to "1.2.0"
    2. For RCs: set release to "0.1%{?dotalpha....", uncomment alphatag* (replace # with %), change to RC1
    3. For non-RCs: set release to "1%{?dotalpha....", comment alphatag* (replace % with #)
    4. in each package dir, run spectool -g *.spec and git annex add *.tar.bz2
    5. commit with message "Release 1.2.0"
    6. perform RPM scratch build of each project (see RPM_Packaging)
    7. tag each project with tito tag --keep-version --auto-changelog-message "Release 1.2.0"
  2. Debian_Packaging: Update changelog files
    1. scripts/changelog.rb -v 1.2.0-1 -m "1.2.0 released" debian/*/*/changelog
  3. Trigger next step of release pipeline: release_packages
  4. Use RPM_Packaging to sign RPMs
  5. Trigger next step of release pipeline: release_mash
  6. Trigger next step of release pipeline: release_test
  7. Trigger next step of release pipeline: release_push_deb and release_push_rpm
  8. Update theforeman.org sections:
    1. _includes/version.html
    2. _includes/latest_news.html entry
    3. security.md for any released CVE fixes

Completion tasks

If releasing the first non-RC release (i.e. 1.2.0), start with:
  1. update $stable class parameter on web class to point to the new version number (see foreman-infra/puppet/modules/web/manifests/init.pp)
  2. deb.theforeman.org, changing stable:
    1. change web's /var/www/freight/apt/*/stable symlinks to the new version number
    2. rm -rf /var/www/vhosts/deb/htdocs/pool/*/stable/
    3. re-run freight cache
  3. Update theforeman.org:
    1. documentation.md change default version
    2. _config.yml quickstart link
    3. _layouts/manual.html latestversion
    4. _layouts/homepage.html quickstart link
    5. plugins/index.md version

If releasing the first release candidate (i.e. RC1), start with:

  1. add version (1.2) to release_plugins_test job

For all releases:

  1. Send announcement e-mail to foreman-announce, CC foreman-users, set reply-to to foreman-users
  2. Link to announcement e-mail on IRC, Twitter, Google+ and update IRC /topic
  3. Add release to "Found in release" list in redmine: http://projects.theforeman.org/custom_fields/4/edit
  4. Update the release schedule on Development_Resources to enter the date and for the following release(s)
  5. Final only: Update Wikipedia Foreman entry at: https://en.wikipedia.org/wiki/Foreman_(software)

After final release

  1. Sync translations from Transifex into develop and update i18n
  2. 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 about 8 years ago · 152 revisions