af07c35f98
* Add description for COLLECTIONS_SCAN_SYS_PATH (#74351) Fixes: #74275 Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com> (cherry picked from commit567361b124
) * lighten navigation background to make section labels easier to read for core docs (#74356) * make section labels for /ansible-core/ docs easier to read, with black text and lighter gray background (cherry picked from commit6119fb0a9a
) * Correct splitext() description, and example (#74377) `splitext()` returns a 2-tuple of strings, and the last element of the return value includes the `.` (cherry picked from commitc295de661c
) * Using "~" instead of "+" for concatination (#74364) Changed FAQ examples to conform with the Jinja documentation: If both values on either side of a plus/+ are numbers, they will be added whereas using "~" will convert all operands into strings and then concatenate them. Closes #73799. (cherry picked from commite6a5245d60
) * Docs - Split Developing collections page, add info on optional module_utils (#74105) * (cherry picked from commitc90922ee36
) * Add weos4 network platform to documentation (#74088) * Add weos4 network platform to documentation * Fix small format issues (cherry picked from commit7ca5dede97
) * Fix typo in Makefile (#74396) Fixed minor typo specfic -> specific (cherry picked from commit4880fee6ca
) * Update complex_data_manipulation.rst (#72509) (cherry picked from commitc2985c491b
) * Update VMware library installation docs (#71219) Depending upon OS/distro, please use pip/pip3. (cherry picked from commitddfc648d37
) * Update AWS dev guides to use collections utils and fragments (#72312) (cherry picked from commitcf08c23b4f
) * Use is_boto3_error_code in 'standard' example (#72313) Use is_boto3_error_code in 'standard' example rather than e.response['Error']['Code'] (#72313) Co-authored-by: Sloane Hertel <shertel@redhat.com> (cherry picked from commit63afb33d86
) * Update Kubernetes collection name in docs (#74440) (cherry picked from commit8d499bbc83
) * Update argcomplete docs links on installation guide (#74410) Link on installation docs is outdated. Switch to currently docs at: https://kislyuk.github.io/argcomplete/ (cherry picked from commitf97787ca74
) * fix spacing to fix header, reorg contributing page (#74421) Co-authored-by: John R Barker <john@johnrbarker.com> (cherry picked from commit9d9b08bece
) * Update first_found documentation (#70502) * import_tasks do not work with loop, use use include_tasks instead * update documentation (cherry picked from commitbacede7a2b
) * Product-related updates. (#74454) (cherry picked from commit34c9ed8a28
) Co-authored-by: Abhijeet Kasurde <akasurde@redhat.com> Co-authored-by: Sandra McCann <samccann@redhat.com> Co-authored-by: Alex Willmer <alex@moreati.org.uk> Co-authored-by: Hublerho <43293510+Hublerho@users.noreply.github.com> Co-authored-by: Ernst Oudhof <17832702+ernst-s@users.noreply.github.com> Co-authored-by: Hu Shuai <hus.fnst@cn.fujitsu.com> Co-authored-by: dhx-mike-palandra <45608336+dhx-mike-palandra@users.noreply.github.com> Co-authored-by: jakelevinez <31458570+jakelevinez@users.noreply.github.com> Co-authored-by: Mark Chappell <mchappel@redhat.com> Co-authored-by: Lidiane Taquehara <lidi.mayra@gmail.com> Co-authored-by: Alex Domoradov <alex.hha@gmail.com> Co-authored-by: Bill Nottingham <notting@redhat.com>
82 lines
3.9 KiB
ReStructuredText
82 lines
3.9 KiB
ReStructuredText
.. _release_managers:
|
|
|
|
**************************
|
|
Release Manager Guidelines
|
|
**************************
|
|
|
|
.. 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
|
|
|
|
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.
|
|
|
|
|
|
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 other
|
|
areas 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 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
|
|
which would want to test the code.
|
|
|
|
|
|
Ansible 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.
|