Project

General

Profile

Actions
History

Development Resources »

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. Their high level tasks and policies are described on Release_Management, while this document covers specific steps (down to individual commands) that need to be run at each step of the release.

Please amend these lists as you see free, and as you find what works and what doesn't work.

These examples are all based around a 1.2 series release, so any reference to "1.2" should be replaced by the current release, "1.1" by your previous release, and "1.3" by the next release.

Near-end of development phase

  1. Announce upcoming branching to discourse development category (example) a month before
  2. Change $latest and $next parameters on web class to point to the new version numbers (see foreman-infra/puppet/modules/web/manifests/init.pp)
  3. File a new release tracker on theforeman.org for "Foreman 1.2 manual" (example)
  4. Refresh unattended templates from the community-templates to Foreman core, by running script/sync_templates.sh
  5. Create a new branch in community-templates for upcoming Foreman release (e.g. 1.2-stable)
  6. Add new languages that are at a reasonable completion on Transifex to develop
  7. Generate a release GPG key using GPG_Keys
    • publish to keyserver
    • security.md on the website, add public key fingerprint to static/keys
    • create releases/1.2/RPM-GPG-KEY-foreman on yum.theforeman.org
  8. Ask plugin authors to start extracting i18n strings and pushing the changes into develop/master git branches so Transiflex can pick it up

Branching for series

When ready to branch for release candidates.

Package build systems

  1. Clone tags and create build targets in Koji using koji/copy-tags-commands.sh in foreman-packaging/rpm/develop or use the tool_belt
    • Make sure you have a kkoji section in ~/.koji/config , you can find instructions in Koji
    • This generates commands that create foreman-1.2-rhel7 etc. as clones of nightly tags and foreman-plugins-1.2-rhel7 etc. with inheritance from the new Foreman tags
    • Untag all git/nightly builds: for t in foreman-1.2-{,nonscl-}rhel7 ; do kkoji list-tagged $t | awk '/git/ {print $1}' | xargs kkoji untag-build $t; done
  2. 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
  3. Add new plugin tags (i.e. 1.2) to Koji plugins mash script (foreman-mash-split-plugins.py), remove old ones (keep three)
  4. Add version (1.2) to these jobs in axes and/or combination filters, remove old ones (keep three)
    1. foremanPluginsRelease
    2. packaging_build_deb_coreproject
    3. packaging_build_deb_dependency
    4. release_test
    5. release_push_deb
    6. release_push_rpm
  5. Clone Debian nightly repos to 1.2 using copy/freight instructions
  6. Edit foreman-packaging's PR template to add 1.2 and remove the old release

Main code repos

  1. Make releases of installer modules, usually new minor or major versions
    1. Currently puppet-puppet, puppet-foreman, puppet-dhcp, puppet-dns, puppet-foreman_proxy, puppet-tftp, puppet-git
  2. In foreman develop run make -C locale tx-update
  3. 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)
  4. In foreman-installer, branch 1.2-stable,
    1. run bundle exec rake pin_modules to change Puppetfile from git references to specific version ranges (e.g. >= 1.3.1 < 1.4.0)
    2. run sed -i '/Puppetfile.lock/d' .gitignore to remove Puppetfile.lock from .gitignore
    3. run librarian-puppet install
    4. commit Puppetfile, Puppetfile.lock and .gitignore changes
  5. 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
  6. 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
  7. In foreman develop commit with message "Bump version to 1.3-develop":
    1. change VERSION to 1.3.0-develop
    2. change package.json version field to 1.3.0
    3. run extras/changelog
  8. In smart-proxy develop commit with message "Bump version to 1.3-develop":
    1. change VERSION to 1.3.0-develop
    2. run extra/changelog
  9. In foreman-selinux develop commit with message "Bump version to 1.3-develop":
    1. change VERSION to 1.3.0-develop
    2. run extras/changelog
  10. In foreman-installer develop commit with message "Bump version to 1.3-develop":
    1. change VERSION to 1.3.0-develop

Other systems

  1. Create release schedule page for next version (1.3) linked from Development_Resources
  2. Add next version number (1.3.0) to Redmine under Versions and all relevant subprojects (installer, proxy, and selinux)
  3. Add first patch release (1.2.1) to Redmine in the same way
  4. Update foreman-dev with translations status to encourage 100% translations before release
  5. Announce string freeze date on discourse and send announcement via https://www.transifex.com/foreman/foreman/announcements/
  6. Create test_1_2_stable.yaml and test_proxy_1_2_stable.yaml for JJB in foreman-infra, remove the oldest version to keep last 3
  7. Ensure current Foreman deprecations for the next release are removed in develop

Rails for RPMs

The Rails stack is built as a separate SCL in Copr but then mirrored for a given Foreman version on yum.theforeman.org. When branching, a version should be created for the Foreman version being released:

# ssh yum.theforeman.org
# cd /var/www/vhosts/yum/htdocs/rails/
# cp -rf foreman-nightly foreman-<version>

The foreman-release-scl RPM then needs updating to point at this new repository in SCL repo file.

Koji needs to be updated to include a new external repository pointing to this new rails repository for builds.

  • ssh
  • edit /etc/mrepo.conf and add foreman-<version> entry for new version
  • Now run: 
    mrepo -ug -f -v foreman-rails-<version>
  • Go back to developer machine
  • Add the new external repo: `koji add-external-repo foreman-rails-<version>-rhel-7 file:///mnt/koji/external-repos/www/foreman-rails-<version>-$arch/RPMS.ror51/`

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.

Writing release notes

  1. Copy website manual content (theforeman.org repo) from previous version to this version (example)
    • add version number to documentation.md dropdown menu
  2. Update manual if applicable for any additional installation steps
  3. Draft release notes in markdown (example), 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. You can auto-generate changes using a script from theforeman.org or use the 'changelog' command in tool_belt
    4. CLI release notes are taken from the hammer-cli and hammer-cli-foreman changelogs
    5. Link to installer changelogs and note versions being used
  4. Get the apipie doc and place it in api/$release_num
  5. Change links in _includes/version.html for 'latest' and 'latest stable'

Preparing code

  1. Request Hammer CLI releases from maintainers if desired
  2. 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
  3. Compare tagged packages in nightly vs. release koji tag and re-tag any updated dependencies that are required
  4. Add a new Redmine version for the next minor, unless the series is EOL
  5. Remove/change release field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
  6. Change Redmine version state to Closed
  7. 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
  8. 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
  9. Add minimum selinux_policy_ver package requirement in foreman-selinux package to the version from the last stable CentOS release.
    1. For example for CentOS 7.5 it's http://mirror.centos.org/centos/7.5.1804/os/x86_64/Packages/selinux-policy-3.13.1-192.el7.noarch.rpm therefore the statement is %define selinux_policy_ver 3.13.1-192

Tagging a release

  1. In foreman 1.2-stable:
    1. run make -C locale tx-update (if Transifex has not switched to the next major release yet, usually after .2)
    2. run script/sync_templates.sh
    3. change VERSION to 1.2.0
    4. change package.json version field to 1.2.0
    5. run extras/changelog
    6. commit with message "Release 1.2.0"
  2. In smart-proxy 1.2-stable commit with message "Release 1.2.0":
    1. change VERSION to 1.2.0
    2. run extra/changelog
  3. In foreman-selinux 1.2-stable commit with message "Release 1.2.0":
    1. change VERSION to 1.2.0
    2. run extras/changelog
  4. In foreman-installer 1.2-stable commit with message "Release 1.2.0":
    1. change VERSION to 1.2.0
  5. Before tagging, make sure the test_xxxx_stable versions of each of the projects are green in http://ci.theforeman.org/
  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)
  10. 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

  1. In foreman-packaging rpm/1.2 branch, change foreman.spec, foreman-proxy.spec, foreman-selinux.spec, foreman-installer.spec, foreman-release:
    1. set version to "1.2.0"
    2. For RCs: set prerelease to RC1
    3. For non-RCs: set release to 1 and remove prerelease
    4. Add a changelog message
    5. in each package dir, remove the old tarball, run spectool -g *.spec and git annex add *.tar.bz2
    6. commit with message "Release 1.2.0"
    7. perform RPM scratch build of each project (see RPM_Packaging)
  2. Create new branches as described in Debian_Packaging
  3. Update changelog files for debs:
    1. scripts/changelog.rb -v 1.2.0-1 -m "1.2.0 released" debian/*/*/changelog
  4. Trigger next step of release pipeline: release_packages
  5. Use RPM_Packaging to sign RPMs
  6. Trigger next step of release pipeline: release_mash
  7. Trigger next step of release pipeline: release_test
  8. Trigger next step of release pipeline: release_push_deb and release_push_rpm

Completion tasks

If releasing the first RC release:
  1. update $latest and $next class parameters on web class to point to the new version number (see foreman-infra/puppet/modules/web/manifests/init.pp)
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 foreman_version and quickstart link
    3. _layouts/manual.html latestversion
    4. plugins/index.md version
    5. add a blog post describing release highlights etc.
  4. If there is any open version on https://projects.theforeman.org/projects/foreman/settings/versions for y-2 (e.g. 1.0.2 when releasing 1.2.0) that hasn't been released, close the version and move any issues assigned to it to the next y-1 release (e.g. 1.1.3).

For all releases:

  1. Update theforeman.org:
    1. release notes from earlier steps (use scripts/release_notes.rb in theforeman.org repository)
    2. _includes/version.html
    3. _includes/latest_news.html entry
    4. security.md for any released CVE fixes
  2. Publish announcement notice in Release Announcements: (https://community.theforeman.org/c/release-announcements)
  3. Link to announcement post on IRC, Twitter, Google+ and update IRC /topic
  4. Update the release schedule on Development_Resources to enter the date and for the following release(s)
  5. Complete Security Process for any released CVE fixes (oss-security list)
  6. Final only: Update Wikipedia Foreman entry at: https://en.wikipedia.org/wiki/Foreman_(software)

Updated by Ewoud Kohl van Wijngaarden over 5 years ago · 211 revisions