Release 22.3

[pradyunsg]

The next pip release is due this month!

[pradyunsg]

@pypa/pip-committers Anyone got bandwidth to pick this up?

[pfmoore]

I can have a go. I may need someone to help with the get-pip release, as the new automation requires signing the commit, and I'm not sure I have working git signing set up.

I'll aim for next weekend, 15/16 Oct - does anyone have any ongoing work that they need to get in before that date? As per our standard policy, I'll pick up whatever is in main at the time of release, so if it doesn't get merged, it won't get into the release 🙂

I'm going to be pretty strict on bugfix releases. So my aim will be ideally no bugfix release, or at worst one if we have serious regressions. As we're so close to the Python 3.11 release, I don't want to put a version of pip into ensurepip, with a bugfix released days later. (I haven't yet decided if we should try to get 22.3 into Python 3.11 - it may be rejected by the RM in any case). Also, multiple bugfixes means more work for virtualenv, more wheels in users' virtualenv seed data directories, etc. Plus it's more work for me 😉 So please, make sure anything that gets merged is as solid as we can make it.

[uranusjr]

Given the concerns of this being close to the 3.11 release, would this be a good time to push back the schedule to line up releases with CPython? We talked about this a bit in the past but there was no timeline proposed, and this is as good a time as any.

[pfmoore]

I'm happy enough to just do 22.3 as per our current schedule, and ask the RMs if it can go into 3.11. If it can't, 3.11 will ship with 22.2.2 and there's no harm done. Any change to our release schedule now will have no effect on what goes into 3.11, other than removing any possibility of 22.3 being in there.

We can change our release schedule for 2023 onward. I think that makes more sense, as long as we start the discussion straight after 22.3 is done¹. Trying to have such a discussion just before a release feels like it just means we'll rush things.

Footnotes

1. As per my point about being strict on bugfixes, I'd be happy to assume that 22.3 will be done by the end of October. ↩

[sbidoul]

does anyone have any ongoing work that they need to get in before that date

#11359 is ready to merge if everyone is happy with the wording of the various warnings now triggered by --install-option.

[pfmoore]

Fine with me, but be aware that if users complain that the deprecation causes issues for them, I won't consider that as a bug, so they'll have to deal with it until 23.0.

[sbidoul]

Fine with me, but be aware that if users complain that the deprecation causes issues for them, I won't consider that as a bug, so they'll have to deal with it until 23.0.

Of course, that is also my approach to this. My question is more about whether pip maintainers think the wording is ok, from a UX perspective.

[pradyunsg]

I'm not sure I have working git signing set up.

Try https://garrytrinder.github.io/2021/09/get-verified-configure-signed-git-commit-signing-on-windows?

---

There's a somewhat major release of packaging due: https://github.com/pypa/packaging/blob/main/CHANGELOG.rst#unreleased

I wanted to get it into the last release but that slipped due to, well, availability of people. It contains a few potentially-disruptive changes though, so... I don't know how compatible that might be with a strict bugfix policy. :)

[pfmoore]

Try https://garrytrinder.github.io/2021/09/get-verified-configure-signed-git-commit-signing-on-windows?

Nope, I don't want anything to do with GPG or having to manage GPG keys. I think I have something set up in 1Password that might work, but if not, someone else will have to sign the release, sorry.

There's a somewhat major release of packaging due: https://github.com/pypa/packaging/blob/main/CHANGELOG.rst#unreleased

Will it be released by the end of next week?

It contains a few potentially-disruptive changes though, so... I don't know how compatible that might be with a strict bugfix policy. :)

If you have concerns about its stability, I'm happy to leave it out of this pip release, but if it goes in then I'm going to stick with the policy. If it goes in and it caused major issues, I'd just revert packaging to the current version - I definitely don't want to get into a cycle of bugfixes with pip trying to patch around packaging changes.

[pradyunsg]

Sounds reasonable. Ping me when you've uploaded to PyPI, and I'll put the get-pip.py changes out. :)

Update: Looks like you can use 1password to sign commits! https://blog.1password.com/git-commit-signing/

[pfmoore]

Update: Looks like you can use 1password to sign commits

Yes, that's what I now have set up. So hopefully it'll work - we'll see 😉 Although I do think the automation should cater for the fact that someone might not have signing working - either check and fail with a message saying what to do in that case, or allow unsigned uploads with a warning. Just blowing up after committing seems suboptimal...

[pradyunsg]

I agree -- I do think that would need someone who doesn't have everything set up to sign by default to contribute that. 🤪