Release manager guidelines

The release manager’s purpose is to ensure a smooth release. To achieve that goal, they need tocoordinate between:

• Developers with commit privileges on the Ansible GitHub repository
• Contributors without commit privileges
• The community
• Ansible documentation team
• Ansible Tower team

Pre-releases: what and why

Pre-releases exist to draw testers. They give people who don’t feel comfortable running from sourcecontrol a means to get an early version of the code to test and give us feedback. To ensure we getgood feedback about a release, we need to make sure all major changes in a release are put intoa pre-release. Testers must be given time to test those changes before the final release. Ideally wewant there to be sufficient time between pre-releases for people to install and test one version fora span of time. Then they can spend more time using the new code than installing the latestversion.

The right length of time for a tester is probably around two weeks. However, for our three-to-four monthdevelopment cycle to work, we compress this down to one week; any less runs the riskof people spending more time installing the code instead of running it. However, if there’s a timecrunch (with a release date that cannot slip), it is better to release with new changes than to holdback those changes to give people time to test between. People cannot test what is not released, sowe have to get those tarballs out there even if people feel they have to install more frequently.

Beta releases

In a beta release, we know there are still bugs. We will continue to accept fixes for these.Although we review these fixes, sometimes they can be invasive or potentially destabilize otherareas of the code.

During the beta, we will no longer accept feature submissions.

Release candidates

In a release candidate, we’ve fixed all known blockers. Any remaining bugfixes areones that we are willing to leave out of the release. At this point we need user testing todetermine if there are any other blocker bugs lurking.

Blocker bugs generally are those that cause significant problems for users. Regressions aremore likely to be considered blockers because they will break present users’ usage of Ansible.

The Release Manager will cherry-pick fixes for new release blockers. The release manager will alsochoose whether to accept bugfixes for isolated areas of the code or defer those to the next minorrelease. By themselves, non-blocker bugs will not trigger a new release; they will only make itinto the next major release if blocker bugs require that a new release be made.

The last RC should be as close to the final as possible. The following things may be changed:

• Version numbers are changed automatically and will differ as the pre-release tags are removed fromthe versions.
• Tests and docs/docsite/ can differ if really needed as they do not break runtime.However, the release manager may still reject them as they have the potential to causebreakage that will be visible during the release process.

Note

We want to specifically emphasize that code (in bin/, lib/ansible/, andsetup.py) must be the same unless there are extraordinary extenuating circumstances. Ifthere are extenuating circumstances, the Release Manager is responsible for notifying groups(like the Tower Team) which would want to test the code.

Ansible release process

The release process is kept in a separate documentso that it can be easily updated during a release. If you need access to edit this, please ask oneof the current release managers to add you.