Skip to content

DOC: Update release instructions #52378

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Apr 3, 2023
Merged

DOC: Update release instructions #52378

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 8 additions & 20 deletions doc/source/development/maintaining.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -437,7 +437,7 @@ which will be triggered when the tag is pushed.
git tag -a v1.5.0.dev0 -m "DEV: Start 1.5.0"
git push upstream main --follow-tags

3. Build the source distribution (git must be in the tag commit):
3. Build the source distribution (git must be in the tag commit)::

./setup.py sdist --formats=gztar --quiet

Expand All @@ -455,25 +455,13 @@ which will be triggered when the tag is pushed.
`automated conda-forge PR <https://github.com/conda-forge/pandas-feedstock/pulls>`_.
Merge it once the CI is green, and it will generate the conda-forge packages.

6. Packages for supported versions in PyPI are built in the
`MacPython repo <https://github.com/MacPython/pandas-wheels>`_.
Open a PR updating the build commit to the released version, and merge it once the
CI is green. To do this type::

git checkout master
git pull --ff-only upstream master
git checkout -B RLS-<version>
sed -i 's/BUILD_COMMIT: "v.*/BUILD_COMMIT: "'v<version>'"/' azure/windows.yml azure/posix.yml
sed -i 's/BUILD_COMMIT="v.*/BUILD_COMMIT="'v<version>'"/' .travis.yml
git commit -am "RLS <version>"
git push -u origin RLS-<version>

7. Download all wheels from the Anaconda repository where MacPython uploads them:
https://anaconda.org/multibuild-wheels-staging/pandas/files?version=<version>
to the ``dist/`` directory in the local pandas copy. You can use the script
``scripts/download_wheels.sh`` to download all wheels at once.

8. Upload wheels to PyPI:
6. Packages for supported versions in PyPI are built automatically from our CI.
Once all packages are build download all wheels from the
`Anaconda repository <https://anaconda.org/multibuild-wheels-staging/pandas/files?version=\<version\>>`_
where our CI published them to the ``dist/`` directory in your local pandas copy.
You can use the script ``scripts/download_wheels.sh`` to download all wheels at once.

7. Upload wheels to PyPI::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are your thoughts about trying pypa's actions to upload to pypi through a github action? https://github.com/pypa/gh-action-pypi-publish

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should surely do that. Downloading and uploading the wheels is not a big deal, but no reason to do it manually.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-1 on this. You can't delete wheels from PyPI if something goes wrong (e.g. some wheels build correctly and others fail) IIRC, so I would rather uploading stay as something manual.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No big deal to automate this part, but if the only problem is not uploading all wheels if one or more fails, I think this can be constrained in the automation (like a CI step that depends on all the wheel generation builds).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can only trigger the second CI step that publishes after the GH release is published?
(I don't know how having a job depend on both the wheel builder workflow and a Github release to be published would work)

Another concerning scenario that I didn't mention before is that if you want to abort the release after the release is tagged, it's hard to do so now, since the wheel builds start as soon as the tag is pushed (You'd need to quickly hit cancel on the builds). I'm probably being overly pessimistic here though ...

Of course, I am not the release manager, so whatever works best for you works for me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having a build that we trigger manually is a good idea. One of the things that I don't like is uploading the wheels to the Anaconda repository, feels quite arbitrary, and makes things harder to understand for someone new to the release. But surely not a big deal. I guess the ideal would be if we could directly upload to the pypi once the wheels are ready, but we had a way to tell pypi when we want to make the new release available.

In any case, running the scripts locally is fine, not much difference between having tbat automated or not in practice. So, happy to keep things like they are for now until we find a solution we really like.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think the dealbreaker is probably syncing the CircleCI wheel builds with it.
(The situation might get better if/when Github decides to make M1/aarch64 runners available).

I'm also not sure of what the point of the anaconda staging repository is anymore. I guess it's just more convenient to download from there than from a Github artifact?


twine upload pandas/dist/pandas-<version>*.{whl,tar.gz} --skip-existing

Expand Down