Foreman 3.9.1 release process

Make this post a wiki (help)


Preparing code: 2023-12-21

Installer Maintainer

  • 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

Release Owner

  • 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 3.9.1 in redmine. issues can be used to generate a comparison between the two.
  • Change Redmine version 3.9.1 state to Closed using close_redmine_version

Tagging a release: 2023-12-21

Release Owner

Release Engineer

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: 2023-12-21

Note it is considered good practice to release on a day when the next day is a working day. This means no releases on Fridays or on the day before a holiday.

Release Engineer

Background documentation

Manual updates: 2023-12-21

Release Owner

After the packages have been released

Release Owner

All pipelines kicked off, will monitor to make sure they go through, and will reply when they’re finished.

There were failures on the release pipeline for the deb tests: foreman-3.9-release-pipeline #20 [Jenkins] Will look into further tomorrow.

I think @evgeni wanted to solve the Debian side with Rebuild against new foreman-js by evgeni · Pull Request #10198 · theforeman/foreman-packaging · GitHub


And always check smoker results, not only for nightly · theforeman/forklift@7d5a7f2 · GitHub will force smoker to actually fail the pipeline instead of us realizing the issue “after the fact” by looking at logs.