DOC: Add release process to the docs #49858
Conversation
| a particular version number. After the release the new pandas version will be available | ||
| in the next places: | ||
|
|
||
| - Git repo with a new tag |
There was a problem hiding this comment.
Would be good to link to https://github.com/pandas-dev/pandas/tags
| versions are released from their branch (e.g. ``1.5.x``). | ||
|
|
||
|
|
||
| Pre-release |
There was a problem hiding this comment.
It would be good to have a section on cutting new branches, detailing what needs to be updated in the CI and when to do it(I don't remember if we cut during release, or do it before the release and start backporting).
| The release process makes a snapshot of pandas (a git commit) available to users with | ||
| a particular version number. After the release the new pandas version will be available | ||
| in the next places: | ||
|
|
There was a problem hiding this comment.
It would be nice to add a prerequisites section, detailing what sort of permissions you need to release and how to ask for them.
| @@ -345,7 +345,126 @@ The benchmarks are scheduled by Airflow. It has a dashboard for viewing and debu | |||
| Release process | |||
| --------------- | |||
|
|
|||
| The process for releasing a new version of pandas can be found at https://github.com/pandas-dev/pandas-release | |||
There was a problem hiding this comment.
Any ideas/plans for the old release repo?
There was a problem hiding this comment.
I'd personally archive it once this is merged, and delete it once we released once or twice without using it.
We may want to move couple of scripts here before that happens, for example to automatically download all the wheels, if we don't automate it in the CI before.
| git commit --allow-empty --author="Pandas Development Team <[email protected]>" -m "RLS: <version>" | ||
| git tag -a v<version> -m "Version <version>" # NOTE that the tag is v1.5.2 with `v` not 1.5.2 | ||
| git push upstream <branch> --follow-tags | ||
| ``` |
There was a problem hiding this comment.
It would be nice to mention that the docs get uploaded automatically from the commit that you tag from.
| - Title: ``Pandas <version>`` | ||
| - Tag: ``<version>`` | ||
| - Files: ``pandas-<version>.tar.gz`` source distribution just generated | ||
| - Description: Copy the description of the last release of the same kind (release candidate, major/minor or patch release) |
There was a problem hiding this comment.
Also mention "Set as release/pre-release" checkboxes should be marked accordingly.
|
|
||
| 1. Agree with the core team on the next topics: | ||
|
|
||
| - Release date |
There was a problem hiding this comment.
It would be nice to mention the usual release cadence for patch/minor releases.
| 4. If not a release candidate, make sure all backporting pull requests to the branch | ||
| being released are merged. | ||
|
|
||
| 5. Create a new issue and milestone for the version after the one being released. |
There was a problem hiding this comment.
After a minor/major release, you would need to create two milestones, right?
One for the patch release (e.g. 1.5.1) and one for the next major version (e.g. 2.0.0).
Co-authored-by: Matthew Roeschke <[email protected]>
|
Thanks @lithomas1 and @mroeschke, great feedback. All comments should be addressed now. |
|
Awesome thanks @datapythonista |
* DOC: Add release process * Update doc/source/development/maintaining.rst Co-authored-by: Matthew Roeschke <[email protected]> * Addressing review comments Co-authored-by: Matthew Roeschke <[email protected]>
This was in a branch in the release repo, and not fully updated. I expect to automate some of the tasks shortly, but having the current release process here while things are improved is still helpful.
The final testing before the release is not added here. I think that's the first thing to move to the CI.
CC: @lithomas1 @mroeschke