Release Management¶

For each major (x.0) and minor release there is a release manager who is responsible for making releases happen. This person is responsible for preparing for releases, ensuring stability of the release, ensuring documentation and announcements are made and generally ensuring a high quality is made.

Components¶

Some release components are pieces of software that the project will maintain and ship (Foreman core, smart proxy etc), while others may be maintained by third parties. In order to release, we need to try and ensure as much of this is working correctly with the release as possible.

1. Foreman
   • branched and released as part of the release process
   • high level of activity, has a reasonably stable develop branch
   • blockers tracked in Redmine where "Release = X"
2. Smart proxy
   • branched and released as part of the release process
   • low-medium level of activity, generally has a stable develop branch
   • blockers tracked in Redmine's smart-proxy project where "Release = X"
3. Foreman SELinux
   • branched and released as part of the release process
   • very low level of activity, generally has a stable develop branch
   • blockers tracked in Redmine's foreman-selinux project where "Release = X"
4. Puppet modules
   • new major/minor releases immediately prior to Foreman releases, patch releases where required
   • releases generally made from master or -stable branches when necessary
   • low-high levels of activity, generally has a stable master branch
   • blockers usually tracked in Redmine's puppet-foreman project where "Release = X"
5. Foreman Installer
   • branched and released as part of the release process
   • composed of Puppet modules above
   • very low level of activity itself, generally has a stable develop branch
   • blockers tracked in Redmine's puppet-foreman project where "Release = X"
6. Debian packaging
   • branched and released as part of the release process
   • low-medium level of activity itself, generally has a stable develop branch
   • blockers tracked in Redmine's rpms project where "Release = X"
7. RPM packaging
   • branched and released as part of the release process
   • medium level of activity itself, generally has a stable develop branch
   • blockers tracked in Redmine's rpms project where "Release = X"
8. Hammer CLI
   • branched and released in parallel to the release process
   • medium level of activity itself, generally has a stable develop branch
   • blockers tracked in Redmine's hammer-cli project
9. Plugins
   • active and larger plugins tend to be branched and released for new major Foreman versions
   • asynchronous release schedules, try to request any compatibility releases are done by the RC1-RC2 timeframe
   • blockers tracked in per-project issue trackers, either Redmine or GitHub
10. theforeman.org
    • copied and updated during the release process
    • medium level of activity itself
    • blockers tracked in per-release tickets on GitHub
11. Translations
    • updated during the release process, between branching and the .2 release
    • medium level of activity itself
    • issues tracked in Transifex per-translation

Issue tracking¶

Redmine is the primary issue tracker for Foreman core projects, where all commits to the "big four" (Foreman, proxy, installer, SELinux) must have a corresponding ticket. This ensures that the release manager can track changes for release notes and backports.

Every closed ticket should have the "Release" flag set on commit, preferably by the release manager.

1. If it contains a refactoring, set it to the next major release
2. If it is a new feature, set it to the next major release
3. If it fixes a regression for something only in develop, set it to the next major release...
4. ..though if it was scheduled for an upcoming release but then got moved to a later one, consider moving both back to the upcoming release
5. If it depends on another ticket or new dependency, set it to the next major release
6. If it is a bug fix that contains no tests, set it to the next major release
7. If it is a bug fix that is well-tested and seems low risk, set it to the next minor release

These aren't hard and fast rules, make decisions based on experience. If in doubt, defer it to the next major release.

When a regression is found - that is, a negative behaviour change between the last release and the upcoming one:

1. Mark the ticket as related to the ticket that caused the regression
2. If the change causing it is not in a stable branch yet, set both tickets to the next major release
3. Set the release flag to the upcoming release

Any open ticket with a release set is a blocker.