"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst" between
ansible-2.14.0.tar.gz and ansible-2.14.1rc1.tar.gz

About: Ansible is an IT Configuration Management, Deployment & Orchestration tool.
Release candidate.

collection_release_with_branches.rst  (ansible-2.14.0)	:	collection_release_with_branches.rst  (ansible-2.14.1rc1)
skipping to change at line 23		skipping to change at line 23
#. Announce your intention to release the collection in a corresponding pinned r elease issue/community pinboard of the collection and in the ``#ansible-communit y`` `Matrix/IRC channel <https://docs.ansible.com/ansible/devel/community/commun ication.html#real-time-chat>`_. Repeat the announcement in any other dedicated c hannels if they exist.		#. Announce your intention to release the collection in a corresponding pinned r elease issue/community pinboard of the collection and in the ``#ansible-communit y`` `Matrix/IRC channel <https://docs.ansible.com/ansible/devel/community/commun ication.html#real-time-chat>`_. Repeat the announcement in any other dedicated c hannels if they exist.
#. Ensure all the other repository maintainers are informed about the time of th e following release.		#. Ensure all the other repository maintainers are informed about the time of th e following release.
Releasing major collection versions		Releasing major collection versions
-------------------------------------		-------------------------------------
The new version is assumed to be ``X.0.0``.		The new version is assumed to be ``X.0.0``.
1. If you are going to release the ``community.general`` and ``community.network `` collections, create new ``backport-X`` and ``needs_backport_to_stable_X`` lab els in the corresponding repositories. Copy the styles and descriptions from the corresponding existing labels.		1. Make sure that ``galaxy.yml`` contains the correct version number ``X.0.0``. If that is not the case, create a PR to update it. This will make sanity tests f ail for all deprecations that have to be removed in ``X.0.0``, so this is potent ially a lot of work and should have been done weeks before the major release.
2. Ensure you are in a default branch in your local fork. These examples use ``m		2. Check the collection for deprecations that are planned for removal in the maj
ain``.		or release that were not reported by the sanity tests. Use past changelogs or ru
		n ``grep -r `X.0.0` plugins/`` in the repository.
		3. If you are going to release the ``community.general`` and ``community.network
		`` collections, create a new ``backport-X`` label in the corresponding repositor
		ies. Copy the styles and descriptions from the corresponding existing labels.
		4. Ensure you are in a default branch in your local fork. These examples use ``m
		ain``.
.. code-block:: bash		.. code-block:: bash
git status		git status
git checkout main # if needed		git checkout main # if needed
3. Update your local fork:		5. Update your local fork:
.. code-block:: bash		.. code-block:: bash
git pull --rebase upstream main		git pull --rebase upstream main
Creating the release branch		Creating the release branch
^^^^^^^^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Create a branch ``stable-X``. Replace ``X`` with a correct number and push it to the **upstream** repository, NOT to the ``origin``.:		1. Create a branch ``stable-X``. Replace ``X`` with a correct number and push it to the **upstream** repository, NOT to the ``origin``.:
skipping to change at line 74		skipping to change at line 78
releases: {}		releases: {}
2. Remove all changelog fragments from ``changelogs/fragments/``. Removing the c hangelog fragments ensures that every major release has a changelog describing c hanges since the last major release.		2. Remove all changelog fragments from ``changelogs/fragments/``. Removing the c hangelog fragments ensures that every major release has a changelog describing c hanges since the last major release.
3. Add and commit all the changes made. Push the branch to the ``origin`` reposi tory.		3. Add and commit all the changes made. Push the branch to the ``origin`` reposi tory.
4. Create a pull request in the collection repository. If CI tests pass, merge t he pull request since the ``main`` branch is expecting changes for the next mino r/major versions		4. Create a pull request in the collection repository. If CI tests pass, merge t he pull request since the ``main`` branch is expecting changes for the next mino r/major versions
5. Switch to the ``stable-X`` branch.		5. Switch to the ``stable-X`` branch.
6. In the ``stable-X`` branch, ensure that ``galaxy.yml`` contains the correct v		6. In the ``stable-X`` branch, verify that ``galaxy.yml`` contains the correct v
ersion number ``X.0.0``. If not, update it.		ersion number ``X.0.0``.
		7. In the ``stable-X`` branch, ensure that ``changelogs/changelog.yml`` contains
		a correct ancestor's version:
		.. code-block:: yaml
		ancestor: X-1.0.0
		releases: {}
7. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X .0.0.yml`` with the content:		8. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X .0.0.yml`` with the content:
.. code-block:: yaml		.. code-block:: yaml
release_summary: |-		release_summary: |-
Write some text here that should appear as the release summary for this ve rsion.		Write some text here that should appear as the release summary for this ve rsion.
The format is reStructuredText, but not a list as for regular changelog fr agments.		The format is reStructuredText, but not a list as for regular changelog fr agments.
This text will be inserted into the changelog.		This text will be inserted into the changelog.
For example:		For example:
.. code-block:: yaml		.. code-block:: yaml
release_summary: This is release 2.0.0 of ``community.foo``, released on YYY Y-MM-DD.		release_summary: This is release 2.0.0 of ``community.foo``, released on YYY Y-MM-DD.
8. In the ``stable-X`` branch, generate the changelogs:		9. In the ``stable-X`` branch, generate the changelogs:
.. code-block:: bash		.. code-block:: bash
antsibull-changelog release --cummulative-release		antsibull-changelog release --cummulative-release
9. In the ``stable-X`` branch, verify that the ``CHANGELOG.rst`` looks as expect ed.		10. In the ``stable-X`` branch, verify that the ``CHANGELOG.rst`` looks as expec ted.
10. In the ``stable-X`` branch, update ``README.md`` so that the changelog link points to ``/tree/stable-X/`` and no longer to ``/tree/main/``, and change badge s respectively, for example, in case of AZP, add ``?branchName=stable-X`` to the AZP CI badge (https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI ?branchName=stable-X).		11. In the ``stable-X`` branch, update ``README.md`` so that the changelog link points to ``/tree/stable-X/`` and no longer to ``/tree/main/``, and change badge s respectively, for example, in case of AZP, add ``?branchName=stable-X`` to the AZP CI badge (https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI ?branchName=stable-X).
11. In the ``stable-X`` branch, add, commit, and push changes to ``README.md``, ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/arc hived fragments to the **upstream** repository, NOT to the ``origin``.		12. In the ``stable-X`` branch, add, commit, and push changes to ``README.md``, ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/arc hived fragments to the **upstream** repository, NOT to the ``origin``.
Publishing the collection		Publishing the collection
^^^^^^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^^^^^^
1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.0.0``. Pushing this tag to the ``upstream`` repository wi ll make Zuul publish the collection on `Ansible Galaxy <https://galaxy.ansible.c om/>`_.		1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.0.0``. Pushing this tag to the ``upstream`` repository wi ll make Zuul publish the collection on `Ansible Galaxy <https://galaxy.ansible.c om/>`_.
.. code-block:: bash		.. code-block:: bash
git tag -n # see current tags and their comments		git tag -n # see current tags and their comments
git tag -a NEW_VERSION -m "comment here" # the comment can be, for exampl e, "community.foo: 2.0.0"		git tag -a NEW_VERSION -m "comment here" # the comment can be, for exampl e, "community.foo: 2.0.0"
git push upstream NEW_VERSION		git push upstream NEW_VERSION
2. Wait until the new version is published on the collection's `Ansible Galaxy <		2. If the collection uses `Zuul <https://github.com/ansible/zuul-config/blob/mas
https://galaxy.ansible.com/>`_ page. It will appear in a list of tarballs availa		ter/README.rst>`_ for publishing its releases, wait until the new version is pub
ble to download.		lished on the collection's `Ansible Galaxy <https://galaxy.ansible.com/>`_ page.
		It will appear in a list of tarballs available to download.
		3. If the release tarball did not appear within several hours after pushing the
		tag, try to re-tag the release commit and push the tag again. In the ``stable-X`
		` branch being at the release commit:
		.. code-block:: bash
		git tag --delete NEW_VERSION
		git push upstream :NEW_VERSION
		git tag -a NEW_VERSION -m "comment here" # the comment can be, for exampl
		e, "community.foo: 2.0.0"
		git push upstream NEW_VERSION
3. Add a GitHub release for the new tag. The title should be the version and con tent, such as - ``See https://github.com/ansible-collections/community.xxx/blob /stable-X/CHANGELOG.rst for all changes``.		4. Add a GitHub release for the new tag. The title should be the version and con tent, such as - ``See https://github.com/ansible-collections/community.xxx/blob /stable-X/CHANGELOG.rst for all changes``.
4. Announce the release through the `Bullhorn Newsletter <https://github.com/ans ible/community/wiki/News#the-bullhorn>`_.		5. Announce the release through the `Bullhorn Newsletter <https://github.com/ans ible/community/wiki/News#the-bullhorn>`_.
5. Announce the release in the pinned release issue/community pinboard of the co llection and in the ``#ansible-community`` `Matrix/Libera.Chat IRC channel <http s://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>` _.		6. Announce the release in the pinned release issue/community pinboard of the co llection and in the ``#ansible-community`` `Matrix/Libera.Chat IRC channel <http s://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>` _.
6. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, ``X.1.0``. Add, commit and push to the **upst ream** repository.		7. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, ``X.1.0``. Add, commit and push to the **upst ream** repository.
Releasing minor collection versions		Releasing minor collection versions
-------------------------------------		-------------------------------------
The new version is assumed to be ``X.Y.0``. All changes that should go into it a re expected to be previously backported from the default branch to the ``stable- X`` branch.		The new version is assumed to be ``X.Y.0``. All changes that should go into it a re expected to be previously backported from the default branch to the ``stable- X`` branch.
Creating the changelogs		Creating the changelogs
^^^^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^^^^
1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correc t version number ``X.Y.0``. If not, update it.		1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correc t version number ``X.Y.0``. If not, update it.
End of changes. 14 change blocks.
18 lines changed or deleted		47 lines changed or added

---