You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Release Drafter guessing the next is 12.4.0 when it's really 13.0.0
Looking at https://github.com/release-drafter/release-drafter#version-resolver, I found that we can change our config so that merging a PR with a particular label, say "Major", will cause release-drafter to bump up to the next major version. See #10279. We could simply label the first PR with the 14.0.0 release notes this way.
The problem is the Release hasn't been published yet during the wheel workflow, and per RELEASING.md it's a manual step after the files have been uploaded.
We could automate publishing (and with the merge of #10279, this is a good idea), but I have another idea.
We originally decided to put the SBOM in the Release as a stopgap because we didn't have it embedded in wheels yet: #9550 (comment).
But #9679 does embed it into wheels, so shall we just skip trying to upload it to the Release? Most Python projects don't put any release assets there, they all go to PyPI.
Enable release immutability Loading
Disallow assets and tags from being modified once a release is publish
This would prevent uploading files after the Release is published.
Even if we don't put assets there, disabling it would potentially prevent an attacker adding malicious wheels there. We can still edit the description.
Activity
radarhere commentedon Oct 22, 2026
Looking at https://github.com/release-drafter/release-drafter#version-resolver, I found that we can change our config so that merging a PR with a particular label, say "Major", will cause release-drafter to bump up to the next major version. See #10279. We could simply label the first PR with the 14.0.0 release notes this way.
radarhere commentedon Oct 22, 2026
Wouldn't the simple solution be to wait until the rest of the files are uploaded (
pypi-publish) and then upload the SBOM? I've created #10280hugovk commentedon Oct 22, 2026
It's about the GitHub "Release" and not the tag. So https://github.com/python-pillow/Pillow/releases/tag/13.0.0 is the last published one, and https://github.com/python-pillow/Pillow/releases/tag/untagged-54142edae7b958b75f1c is the next unpublished one.
The problem is the Release hasn't been published yet during the wheel workflow, and per RELEASING.md it's a manual step after the files have been uploaded.
We could automate publishing (and with the merge of #10279, this is a good idea), but I have another idea.
We originally decided to put the SBOM in the Release as a stopgap because we didn't have it embedded in wheels yet: #9550 (comment).
But #9679 does embed it into wheels, so shall we just skip trying to upload it to the Release? Most Python projects don't put any release assets there, they all go to PyPI.
hugovk commentedon Oct 22, 2026
Separately, let's turn this on at https://github.com/python-pillow/Pillow/settings
This would prevent uploading files after the Release is published.
Even if we don't put assets there, disabling it would potentially prevent an attacker adding malicious wheels there. We can still edit the description.
radarhere commentedon Oct 22, 2026
If that's the standard, then sure.
Sounds good
hugovk commentedon Oct 22, 2026
I've enabled release immutability at https://github.com/python-pillow/Pillow/settings.