Release manager guidelines

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

    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.

    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.

    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.

    Note

    We want to specifically emphasize that code (in , , and) 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.