mirror of https://github.com/ansible/ansible.git
Documentation on how to make a release. (#31426)
* Release Engineering Docs with pointer to the Docs on how to actually make the release.pull/34158/head
parent
ebd096a732
commit
94d952f94b
@ -0,0 +1,29 @@
|
|||||||
|
GitHub Admins
|
||||||
|
=============
|
||||||
|
|
||||||
|
.. contents:: Topics
|
||||||
|
|
||||||
|
GitHub Admins have more permissions on GitHub than normal contributors. There are
|
||||||
|
a few responsibilities that come with that increased power.
|
||||||
|
|
||||||
|
|
||||||
|
Add and Remove Committers
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke
|
||||||
|
contributors' ability to commit on their own. GitHub Admins are the people who have the power to
|
||||||
|
actually manage the GitHub permissions.
|
||||||
|
|
||||||
|
|
||||||
|
Change Branch Permissions for Release
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
When we make releases we make people go through a :doc:`release_manager` to push commits to that
|
||||||
|
branch. The GitHub admins are responsible for setting the branch so only the Release Manager can
|
||||||
|
commit to the branch when the release process reaches that stage and later opening the branch once
|
||||||
|
the release has been made. The Release manager will let the GitHub Admin know when this needs to be
|
||||||
|
done.
|
||||||
|
|
||||||
|
.. seealso:: The `GitHub Admin Process Docs
|
||||||
|
<https://github.com/ansible/ansible/blob/devel/hacking/release-branches.rst>`_ for instructions
|
||||||
|
on how to change branch permissions.
|
@ -0,0 +1,80 @@
|
|||||||
|
Release Managers
|
||||||
|
================
|
||||||
|
|
||||||
|
.. contents:: Topics
|
||||||
|
|
||||||
|
The release manager's purpose is to ensure a smooth release. To achieve that goal, they need to
|
||||||
|
coordinate between:
|
||||||
|
|
||||||
|
* Developers with Commit privileges on the `Ansible github repository <https://github.com/ansible/ansible/>`_
|
||||||
|
* 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 source
|
||||||
|
control a means to get an early version of the code to test and give us feedback. To ensure we get
|
||||||
|
good feedback about a release, we need to make sure all major changes in a release are put into
|
||||||
|
a pre-release. Testers must be given time to test those changes before the final release. Ideally we
|
||||||
|
want there to be sufficient time between pre-releases for people to install and test one version for
|
||||||
|
a span of time. Then they can spend more time using the new code than installing the latest
|
||||||
|
version.
|
||||||
|
|
||||||
|
The right length of time for a tester is probably around two weeks. However, for our three-to-four month
|
||||||
|
development cycle to work, we compress this down to one week; any less runs the risk
|
||||||
|
of people spending more time installing the code instead of running it. However, if there's a time
|
||||||
|
crunch (with a release date that cannot slip), it is better to release with new changes than to hold
|
||||||
|
back those changes to give people time to test between. People cannot test what is not released, so
|
||||||
|
we have to get those tarballs out there even if people feel they have to install more frequently.
|
||||||
|
|
||||||
|
|
||||||
|
What is Beta?
|
||||||
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
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 other
|
||||||
|
areas of the code.
|
||||||
|
|
||||||
|
During the beta, we will no longer accept feature submissions.
|
||||||
|
|
||||||
|
|
||||||
|
What is a Release Candidate?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
In a release candidate, we've fixed all known blockers. Any remaining bugfixes are
|
||||||
|
ones that we are willing to leave out of the release. At this point we need user testing to
|
||||||
|
determine if there are any other blocker bugs lurking.
|
||||||
|
|
||||||
|
Blocker bugs generally are those that cause significant problems for users. Regressions are
|
||||||
|
more 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 also
|
||||||
|
choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor
|
||||||
|
release. By themselves, non-blocker bugs will not trigger a new release; they will only make it
|
||||||
|
into 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 from
|
||||||
|
the versions.
|
||||||
|
* Tests and :file:`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 cause
|
||||||
|
breakage that will be visible during the release process.
|
||||||
|
|
||||||
|
.. note:: We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and
|
||||||
|
:file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances. If
|
||||||
|
there are extenuating circumstances, the Release Manager is responsible for notifying groups
|
||||||
|
(like the Tower Team) which would want to test the code.
|
||||||
|
|
||||||
|
|
||||||
|
Release Process
|
||||||
|
===============
|
||||||
|
|
||||||
|
The release process is kept in a `separate document
|
||||||
|
<https://docs.google.com/document/d/10EWLkMesi9s_CK_GmbZlE_ZLhuQr6TBrdMLKo5dnMAI/edit#heading=h.ooo3izcel3cz>`_
|
||||||
|
so that it can be easily updated during a release. If you need access to edit this, please ask one
|
||||||
|
of the current release managers to add you.
|
Loading…
Reference in New Issue