26.1 release plans

[henryiii]

I'd like to get a release out pretty soon so pip will have plenty of time to adopt 26.1.

Looking at the open PRs, these should go in:

• feat: add handling for Emscripten wheels tags per PEP 783 #804 (PEP accepted)
• Rename format_full_version to _format_full_version to make it visibly private #1125
• Implement is_unsatisfiable on SpecifierSet using ranges #1119: I think this good to get in?
• tests: do not reload the tags module #1152
• feat: option to validate compressed tag set sort order in parse_wheel_filename #1150: This is now opt-in, so I think it's safe to target 26.1.

I'd like to drop Python 3.8 (unless someone wants to keep it) shortly after 26.1, so anything that gets pushed off won't be available for 3.8. FYI, cibuildwheel/manylinux plans to drop 3.8 on 2025-05-05 when 3.15b1 is released.

Fine to delay:

• packaging.version as a CLI tool #795
• Fix RHS marker-variable version comparisons #1112 / Fix marker version comparison when variable is on the RHS (issue #934) #1126: This improves compliance with the spec, but adds something that hasn't been possible before (reversed marker comparison order), and there's two to pick from, so I think there's no hurry. If uv does this too, there's also the option to match the spec to the implementation. I like the later one better. I think we need to discuss the potential of changing the spec to match the way that the libraries currently implement this instead.
• feat: add API for markers as a structured tree #1145: I think the previous issue needs to be resolved first.

And these will not go in:

• feat: filenames #1113: Looks like this might get updated to handle variants, shouldn't be rushed.
• Probably anything else I didn't have something to say about

(Also, while I am a maintainer, this is not an official plan we have agreed on, it's just a proposal from me, other maintainers can propose something different. CC @brettcannon and @notatallshaw, for example. Feel free to edit any text as desired.)

I think we could be ready for a release quite soon.

[notatallshaw]

Apologies, I've been completely tied up this week and will continue be until Friday evening, but this week I will get my PR in a fit state to merge and take a look over the other ones.

Excited for 26.1, a lot of progress has been happening!

[henryiii]

#1156

This time when building the changelog I kept a markdown version around (in PR description now) instead of having to recreate it for the GH release, which is hard due to the names being removed in the RST version. :)

[henryiii]

@brettcannon, @dstufft, @pradyunsg, or @pfmoore: tagged, deployment is awaiting your approval. https://github.com/pypa/packaging/actions/runs/24401721381 I think is where you can find the approval request.

[pfmoore]

It doesn't particularly matter, but I'm curious why I have the ability to approve this - I'm not a packaging maintainer. I'd have expected packaging releases to be approved by the project maintainers...?

In any case I'll leave it to someone who is a maintainer to do the approval.

[henryiii]

I got that list from PyPI: https://pypi.org/project/packaging/ Assuming you are pf_moore on PyPI, you have the ability to push releases there, so that's why it's here too. :)

The main reason I want the approval pool here to match PyPI is that if there is a problem, only those four people can yank a release. Approving here means you are aware of the release and can react if there's an issue that needs yanking.

(PS: I don't think I can tell maintainers from owners, only owners can yank or delete releases. Or add trusted publishers. Only push releases via classic tokens AFAIK...)

[pfmoore]

I think I'm in a weird position because I'm a PyPA owner - so I have all sorts of privileges I don't tend to need or exercise. What surprised me though was that a release on this project needed someone to click an "approve" button at all (and I can't see what in the workflow definition makes that the case). None of the other projects I have trusted publishing on work like that.

This is off-topic, though, so I'll stop distracting from the main point of this issue 🙂

[notatallshaw]

No, I think this is valid to this discussion, 26.1 is waiting approval because of this list, we should clean up the approvers and owners on GitHub and PyPI to reflect modern maintainer list.

[henryiii]

It's self imposed, manually synced to the public PyPI maintainer list:

The release is done except for the approval, so I think it's fine to go off on a related tangent. :)

I'm fine to update it but only if the PyPI owners change, since I think it's important to have someone who can yank releases aware of the release. (given that releases can be un-yanked, I really think PyPI maintainers should be able to yank releases! But that's off-topic, and I can't tell who's a maintainer vs. owner anyway.)

[pfmoore]

Ah, I didn't know that was possible. Yes, this should probably be fixed so that the github owner list, the PyPI owners, and the release authoriser list are all the same.

This is the list of packaging committers from GitHub:

[brettcannon]

https://pypi.org/project/packaging/26.1/