Document release process #7673
Document release process #7673
Conversation
Dreamsorcerer
added
the
bot:chronographer:skip
|
Best put it under |
We don't really want it on the main website, right? It's only relevant to aiohttp-admins, so being accessible only in the codebase makes more sense to me. |
|
Honestly, I've seen people having this in a separate docs section, somewhere close to the contributing guides so I typically prefer it. It's not something secret. We document how to add changelog fragments there too, which is kinda related. |
|
I also know that some people dislike polluting the repo root with many files, which is sometimes a source of complaints.. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #7673 +/- ##
==========================================
+ Coverage 97.36% 97.41% +0.04%
==========================================
Files 106 107 +1
Lines 31630 32263 +633
Branches 3619 3750 +131
==========================================
+ Hits 30797 31428 +631
- Misses 630 632 +2
Partials 203 203
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| :orphan: | ||
|
|
There was a problem hiding this comment.
Can we include this into the ToC instead of orphaning? Doesn't linking it from the other document not make this automatically?
| :orphan: |
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.
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.
@Dreamsorcerer in other projects, I started making it a separate TOC, see:
- https://ansible-pylibssh.readthedocs.io/en/latest/contributing/release_guide/
- https://cheroot.cherrypy.dev/en/latest/devguide/
- https://yarl.aio-libs.org/en/latest/contributing/release_guide/
I'd like to implement a similar structure here, eventually.
|
|
||
| #. 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.
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.
@Dreamsorcerer I think I was testing with --draft and always passing --version. Though, I suppose Towncrier has some ability to import the version from a Python module. That doesn't always work, not for C-extension based codebases, anyway.
There was a problem hiding this comment.
Right, I was wondering where it kept getting the version from. I just corrected it in the file manually.
There was a problem hiding this comment.
@Dreamsorcerer I left some notes. They are not mandatory and can be fixed in follow-ups. That's up to you.
|
@webknjaz Would it be fine to delete some of the oldest 3.x branches? Not sure if there's a reason they've been kept around, but they just seem so old now that they are not useful, and it's a bit of a nuisance that I now have to scroll to select the correct branch in a backport PR (all upto 3.8 are selectable without scrolling). |
Backport to 3.9: 💚 backport PR created✅ Backport PR branch: Backported as #7909 🤖 @patchback |
(cherry picked from commit aa7d1a8)
Backport to 3.10: 💚 backport PR created✅ Backport PR branch: Backported as #7910 🤖 @patchback |
(cherry picked from commit aa7d1a8)
**This is a backport of PR #7673 as merged into master (aa7d1a8).** Co-authored-by: Sam Bull <[email protected]>
**This is a backport of PR #7673 as merged into master (aa7d1a8).** Co-authored-by: Sam Bull <[email protected]>
@Dreamsorcerer I think it's fine for as long as there are tags on the tops of those branches. |
| @@ -0,0 +1,57 @@ | |||
| :orphan: | |||
There was a problem hiding this comment.
@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.
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.
@webknjaz We really need to document this somewhere. Is this an acceptable place?