Skip to content
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

Bump pypa/cibuildwheel from 2.18.1 to 2.19.1 #4381

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
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
2 changes: 1 addition & 1 deletion .github/workflows/pypi_upload.yml
Original file line number Diff line number Diff line change
Expand Up @@ -89,7 +89,7 @@ jobs:

steps:
- uses: actions/checkout@v4
- uses: pypa/cibuildwheel@v2.18.1
- uses: pypa/cibuildwheel@v2.19.1
with:
only: ${{ matrix.only }}

Expand Down
9 changes: 4 additions & 5 deletions docs/contributing/release_process.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,8 +29,8 @@ frequently than monthly nets rapidly diminishing returns.
**You must have `write` permissions for the _Black_ repository to cut a release.**

The 10,000 foot view of the release process is that you prepare a release PR and then
publish a [GitHub Release]. This triggers [release automation](#release-workflows) that
builds all release artifacts and publishes them to the various platforms we publish to.
publish a [GitHub Release]. This triggers [release automation](#release-workflows) that builds
all release artifacts and publishes them to the various platforms we publish to.

We now have a `scripts/release.py` script to help with cutting the release PRs.

Expand Down Expand Up @@ -96,9 +96,8 @@ In the end, use your best judgement and ask other maintainers for their thoughts

## Release workflows

All of _Black_'s release automation uses [GitHub Actions]. All workflows are therefore
configured using YAML files in the `.github/workflows` directory of the _Black_
repository.
All of _Black_'s release automation uses [GitHub Actions]. All workflows are therefore configured
using YAML files in the `.github/workflows` directory of the _Black_ repository.

They are triggered by the publication of a [GitHub Release].

Expand Down
14 changes: 7 additions & 7 deletions docs/usage_and_configuration/black_docker_image.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,16 +8,16 @@ _Black_ images with the following tags are available:
- release numbers, e.g. `21.5b2`, `21.6b0`, `21.7b0` etc.\
β„Ή Recommended for users who want to use a particular version of _Black_.
- `latest_release` - tag created when a new version of _Black_ is released.\
β„Ή Recommended for users who want to use released versions of _Black_. It maps to [the latest release](https://github.com/psf/black/releases/latest)
of _Black_.
β„Ή Recommended for users who want to use released versions of _Black_. It maps to
[the latest release](https://github.com/psf/black/releases/latest) of _Black_.
- `latest_prerelease` - tag created when a new alpha (prerelease) version of _Black_ is
released.\
β„Ή Recommended for users who want to preview or test alpha versions of _Black_. Note that
the most recent release may be newer than any prerelease, because no prereleases are created
before most releases.
β„Ή Recommended for users who want to preview or test alpha versions of _Black_. Note
that the most recent release may be newer than any prerelease, because no prereleases
are created before most releases.
- `latest` - tag used for the newest image of _Black_.\
β„Ή Recommended for users who always want to use the latest version of _Black_, even before
it is released.
β„Ή Recommended for users who always want to use the latest version of _Black_, even
before it is released.

There is one more tag used for _Black_ Docker images - `latest_non_release`. It is
created for all unreleased
Expand Down
Loading