-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document release process #7673
Document release process #7673
Changes from all commits
a0d5109
130f699
a855064
f303a85
bd2227f
9e8730d
127e864
e227e7e
c3d7c29
8b8e999
037c9a1
7060637
96bf205
1d5b1e6
a69f206
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
@@ -0,0 +1,57 @@ | ||||
:orphan: | ||||
|
||||
Comment on lines
+1
to
+2
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we include this into the ToC instead of orphaning? Doesn't linking it from the other document not make this automatically?
Suggested change
For inspiration, there's some release sections in public docs: https://pip.pypa.io/en/stable/development/release-process/#id5 / https://setuptools.pypa.io/en/latest/development/releases.html#release-process / https://ansible-pylibssh.readthedocs.io/en/latest/contributing/release_guide/#release-guide / https://scikit-hep.org/pyhf/development.html#publishing / https://devguide.python.org/developer-workflow/development-cycle/ There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Apparently, the meaning of orphan is just that it is not included it a toctree, not that it is undiscoverable (something which is confusing, as most users expect orphan to mean the latter)... I'm not really sure we want to include it in a toctree? The sidebar has a link directly to contributing, I'm not sure it makes sense to include another link from the sidebar for something almost nobody needs to see. And I don't really see any other toctrees to use. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Dreamsorcerer in other projects, I started making it a separate TOC, see:
I'd like to implement a similar structure here, eventually. |
||||
Instructions for aiohttp admins | ||||
=============================== | ||||
|
||||
This page is intended to document certain processes for admins of the aiohttp repository. | ||||
For regular contributors, return to :doc:`contributing`. | ||||
|
||||
.. contents:: | ||||
:local: | ||||
|
||||
Creating a new release | ||||
---------------------- | ||||
|
||||
.. note:: The example commands assume that ``origin`` refers to the ``aio-libs`` repository. | ||||
|
||||
To create a new release: | ||||
|
||||
#. Start on the branch for the release you are planning (e.g. ``3.8`` for v3.8.6): ``git checkout 3.8 && git pull`` | ||||
#. Update the version number in ``__init__.py``. | ||||
#. Run ``towncrier``. | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No args? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I didn't use any. Do you have any arguments when you run it? I was just guessing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Dreamsorcerer I think I was testing with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, I was wondering where it kept getting the version from. I just corrected it in the file manually. |
||||
#. Check and cleanup the changes in ``CHANGES.rst``. | ||||
#. Checkout a new branch: e.g. ``git checkout -b release/v3.8.6`` | ||||
#. Commit and create a PR. Once PR is merged, continue. | ||||
#. Go back to the release branch: e.g. ``git checkout 3.8 && git pull`` | ||||
#. Add a tag: e.g. ``git tag -a v3.8.6 -m 'Release 3.8.6'`` | ||||
#. Push the tag: e.g. ``git push origin v3.8.6`` | ||||
Dreamsorcerer marked this conversation as resolved.
Show resolved
Hide resolved
|
||||
#. Monitor CI to ensure release process completes without errors. | ||||
|
||||
Once released, we need to complete some cleanup steps (no further steps are needed for | ||||
non-stable releases though). If doing a patch release, we need to do the below steps twice, | ||||
first merge into the newer release branch (e.g. 3.8 into 3.9) and then to master | ||||
(e.g. 3.9 into master). If a new minor release, then just merge to master. | ||||
|
||||
#. Switch to target branch: e.g. ``git checkout 3.9 && git pull`` | ||||
#. Start a merge: e.g. ``git merge 3.8 --no-commit --no-ff --gpg-sign`` | ||||
#. Carefully review the changes and revert anything that should not be included (most | ||||
things outside the changelog). | ||||
#. To ensure change fragments are cleaned up properly, run: ``python tools/cleanup_changes.py`` | ||||
#. Commit the merge (must be a normal merge commit, not squashed). | ||||
#. Push the branch directly to Github (because a PR would get squashed). When pushing, | ||||
you may get a rejected message. Follow these steps to resolve: | ||||
|
||||
#. Checkout to a new branch and push: e.g. ``git checkout -b do-not-merge && git push`` | ||||
#. Open a *draft* PR with a title of 'DO NOT MERGE'. | ||||
#. Once the CI has completed on that branch, you should be able to switch back and push | ||||
the target branch (as tests have passed on the merge commit now). | ||||
#. This should automatically consider the PR merged and delete the temporary branch. | ||||
|
||||
Back on the original release branch, append ``.dev0`` to the version number in ``__init__.py``. | ||||
|
||||
If doing a minor release: | ||||
|
||||
#. Create a new release branch for future features to go to: e.g. ``git checkout -b 3.10 3.9 && git push`` | ||||
#. Update ``target-branch`` for Dependabot to reference the new branch name in ``.github/dependabot.yml``. | ||||
#. Delete the older backport label (e.g. backport-3.8): https://github.com/aio-libs/aiohttp/labels | ||||
#. Add a new backport label (e.g. backport-3.10). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Dreamsorcerer also, since you put a link to this doc from another doc, Sphinx won't consider it orphan anymore. So it's not really needed either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned above, that's not what orphan means to Sphinx. It literally just means that it is not in a toctree, not that it is unreachable. So, it is needed in its current state.