Release 25.1 (April)

[ichard26]

I'm mostly filing this now as I have some interest in being the next RM. Both to increase the maintainers available to do a release, and to give @sbidoul a break :)

There are several deprecations scheduled for removal in the 25.1 milestone which definitely makes it somewhat precarious, but I'd be happy to at least learn the mechanical parts and have someone else help me through the decision-making. pip 25.3 (October) is likely going to be a busy time for me, so 25.2 would be the best time for me to learn the release flow.

Any objections or thoughts? cc @pypa/pip-committers

[notatallshaw]

I'm in agreement that having different maintainers wear the RM hat is important, both for different maintainers being familiar with the process and making sure the release instructions are correct. Also, I'd be happy to volunteer for a different release later in the year.

[pfmoore]

I'd like to do a release sometime, just to check the new process on Windows. My open source time has been severely limited recently, but I can try to do 25.1 (and if @ichard26 or @notatallshaw want a blow-by-blow account of the process I used, I'm happy to do some form of running commentary or walkthrough).

[ichard26]

Sure, we can do that. It'd be nice to shadow an experienced RM for a release cycle before being a RM. In my original post, I got the release months mixed up. 25.2 (July) is probably the best time for me be the RM (unless I go on vacation then, but I haven't decided yet). I'm still available for 25.1 if availabilities change.

I've assigned the issue to you to mark you as our tentative RM for pip 25.1.

I'm happy to do some form of running commentary or walkthrough

Yes please! The mechanical work is likely probably well-documented (updating get-pip...?) but it's the decision-making and things to look out for I'd appreciate. (Perhaps we could turn your commentary into informal checklists?)

[notatallshaw]

One thing that needs to be decided is whether to drop support for Python 3.8 (#12989).

My main concern is that pip can't vendor urllib 2.x until Python 3.10+, and I don't know the timeline for urllib 1.x support ending, the docs currently say "continue supporting v1.26.x releases with both security and bug fixes for the forseeable future": https://urllib3.readthedocs.io/en/1.26.6/v2-roadmap.html, but 2.x has been out for nearly two years now.

[ichard26]

We can simply ask @sethmlarson. Do you have plans to drop support for urllib3 1.x? Either entirely, or only on Python 3.8 specifically?

[pfmoore]

If we get consensus on #12989 to drop support for Python 3.8, and someone does the work to create the necessary PR, that's fine by me with my RM hat on. It's not related to urllib3 (although maybe getting consensus will be affected by the urllib3 position - I doubt it, but it's possible).

As far as I can see, with regard to urllib3 version 2, we're blocked until we drop support for Python 3.9 - at least that seems to be what this comment suggests. That's not going to be until pip 26.0 at the absolute earliest (Python 3.9 goes EOL just after pip 25.3 will be released).

Regardless, anything related to the urllib3 migration should be discussed on #12857. And I'm going to say that barring something unexpected, it won't be happening in 25.1.

Either entirely, or only on Python 3.8 specifically?

I'm pretty strongly against shipping two vendored copies of urllib3 so that we can pick which one to use based on the Python version. And having different wheels for different Python versions is a big enough change that it would need its own issue to track it (and I'd probably say no to including it in 25.1 anyway).

[ichard26]

I wasn't implying that we'd vendor two copies of urllib3. I was making the distinction since if urllib3 1.x is going to be completely unsupported, then we have a bigger problem that just Python 3.8 support since we aren't a position to properly support an unmaintained HTTP library. If urllib3 1.x is planning to drop Python 3.8 support, then pip can simply move in the same direction and also drop Python 3.8 support.

and someone does the work to create the necessary PR

I had a PR open to drop Python 3.8 support (#13190) , but it got no attention so I gave up and closed it. I don't care strongly enough to push for it.

And I'm going to say that barring something unexpected, it won't be happening in 25.1.

It won't because there is no point. We aren't planning to drop Python 3.9 for a while and before then, upgrading to urllib3 2.x is blocked.

I'm honestly pretty confused here. I don't want us to consider anything BUT potentially dropping support for Python 3.8 this release. That is all, nothing more.

[pfmoore]

I had a PR open to drop Python 3.8 support (#13190) , but it got no attention so I gave up and closed it.

I wasn't a huge fan of the size of the PR. That may be part of the reason you got little interest - 197 files changed is way too much to review. I don't think we normally run pyupgrade like this when we drop support, we just leave the code unchanged and gradually use newer constructs when appropriate. Also, why deliberately break people who want to continue using Python 3.8 (unsupported, of course)? Sorry - I probably could have commented to that effect at the time.

I'm honestly pretty confused here.

Me too. Let's assume urllib3 is irrelevant (for 25.1, at least).

The relevant issue for dropping 3.8 support is #12989, which feels inconclusive to me right now. So we won't be dropping 3.8 in 25.1 unless someone pushes there for consensus. But personally, I don't think supporting 3.8 is causing us any issues, and download numbers (8.3% in December isn't that small) make me inclined to be cautious.

[ichard26]

I don't think we normally run pyupgrade like this when we drop support

We did for Python 3.7. It was much a smaller change, however (see the pyupgrade commit in #11944).

Also, why deliberately break people who want to continue using Python 3.8 (unsupported, of course)?

It's not so much that I'm trying to break people stuck on Python $version, but that if we're doing to make the formal designation that $version is unsupported, we should fully take advantage of the new/improved constructs. The codebase is going to quickly regress without automated testing, regardless. It'd only take one modern typing import in some unrelated change to cause pip to immediately crash on an unsupported Python version.

Now, I'm actually pretty ambivalent about switching the codebase to 3.8+ typing constructs wholesale specifically. I do like the changes, but if we don't want to review it, then meh, I don't care. We'll just need to disable of the pyupgrade rules in Ruff.

---

I'm pretty sure we're talking past each other at this point, so all else I'm going to say is that I don't care if we drop Python 3.8 this release or not. I won't be picking up that task, and frankly, pip is foundational enough where it'd be nice to maintain official support when it's not a burden (and it isn't).

[pfmoore]

It was much a smaller change, however

That's probably why I missed it 🙂

I'm pretty sure we're talking past each other at this point, so all else I'm going to say is that I don't care if we drop Python 3.8 this release or not. I won't be picking up that task, and frankly, pip is foundational enough where it'd be nice to maintain official support when it's not a burden (and it isn't).

IMO, not so much talking past each other as debating philosophy 🙂 I also don't care if we drop Python 3.8 support - I won't be doing the work, but I won't object if someone wants to.

It sounds like a big part of the pyupgrade stuff was typing changes. I'm a typing skeptic, and find the rapid pace of change in type annotations frustrating and annoying. So I tend to view things like this as evidence that the cost/benefit case for type annotations isn't necessarily as favourable as people like to claim. But as long as I can continue to ignore the whole thing and let someone else deal with it, I'm not going to worry.

[notatallshaw]

I'm honestly pretty confused here. I don't want us to consider anything BUT potentially dropping support for Python 3.8 this release. That is all, nothing more.

Sorry, I started this additional discussion, I should of been more explicit in my reasoning, my concern about urllib3 1.x support and Python 3.8 is that pip is unlikely to drop Python 3.9 support until some amount of time has passed since Python 3.8 support has been dropped, so it's more of a scheduling thing than a direct consequence thing.

I wasn't a huge fan of the size of the PR.

There's no way to avoid that when we increase the minimum supported Python while we have the upgrade rules turned on: #12936

We would either need to disable the pyupgrade rules or have a different minimum version of Python in ruff only to 3.8.

That may be part of the reason you got little interest

For me I was waiting for either release manager input or a consensues on #12989 before reviewing the PR, at a cursory glance it looked fine. But reading your response I'll confine any further discussion to #12989.

So I tend to view things like this as evidence that the cost/benefit case for type annotations isn't necessarily as favourable as people like to claim

I would agree with this if updating the typing syntax was manual, but almost all updates tend to be done by ruffs auto fixer. And while ruff is a relatively young tool, it is widely deployed by open source and closed source projects, I have a lot of trust that if the fixes are automatic that they have a high degree of safety. My main point for reviewing a PR like this would be seeing there are distinct commits where auto fixing is used and where manual fixes need to be applied.

[pfmoore]

I created #13236 to discuss the pyupgrade rules, and whether we should automatically apply them when we desupport a Python version.