Foreman 2.3.2 release process

Make this post a wiki

Manual updates: 2021-01-12

Preparing code: 2021-01-12

  • 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
  • Add a new Redmine version for the next minor, unless the series is EOL. Be sure the version is set to sharing with subprojects.
  • Remove/change target version field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
  • Ensure that code in git matches issues fixed in 2.3.2 in redmine. issues.rb can be used to generate a comparison between the two.
  • Change Redmine version 2.3.2 state to Closed

Tagging a release: 2021-01-12

  • In foreman 2.3-stable:
    • Make sure test_2_3_stable is green
    • Tag the release using tag.sh tag.sh 2.3.2 && git push upstream 2.3-stable --follow-tags
  • In smart-proxy 2.3-stable:
  • In foreman-selinux 2.3-stable:
    • Tag the release using tag.sh tag.sh 2.3.2 && git push upstream 2.3-stable --follow-tags
  • In foreman-installer 2.3-stable:
    • Tag the release using tag.sh tag.sh 2.3.2 && git push upstream 2.3-stable --follow-tags
  • Run the Jenkins Tarballs Release to create tarballs
  • Update release version similar to here
  • Sign Tarballs

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: 2021-01-12

Background documentation

After the packages have been released

  • Update the versions on the website in version and latest news
  • Announce the release on Discourse
  • Update the topic in #theforeman channel on Freenode
  • Share the release announcement on twitter
  • Release pipeline will trigger plugins test pipeline, which doesn’t block releases but can be used to understand known issues around plugin compatibility with Foreman 2.3.