Do we want to change our release cadence?

[pradyunsg]

I can think of two good reasons:

• We release too often, given that we’ve had at least two occasions of closing the previous release issue only to open the new one, for the release that is due in the month starting next week.
• Or releases are oddly timed for the Python 3.X.0 releases, with the annual cadence.

If we do decide to do this, it will likely affect our deprecation policy.

[pradyunsg]

@pypa/pip-committers ^

[pfmoore]

I could support a slower release cadence - what were you thinking of? Twice a year, or annually?

In addition to the deprecation policy, we should consider what we'd do about bugfixes. Although we might find the current release cadence too fast, slowing down might increase the pressure from users for getting access to bugfixes between releases. But we can't do bugfix releases with our current development policy, as features and bugfixes all land on main, and I don't think that we want to commit our RMs to cherry-picking bugfixes to manage a bugfix release.

So my view is that if we change, we should make it clear that we will not be releasing intermediate bugfix releases, and that we'll maintain our current approach of having a short post-release period when we will do bugfix releases for major issues with the release, but that's all.

Otherwise, we're increasing the commitment required from our RMs (being available to handle bugfix releases for the whole inter-release period) and that might end up actually making it harder to get RMs.

Edit: I'd also say that I personally think that we made a mistake with the recent cases where we left the release open as long as we did. I'd also be in favour of changing the policy to keep the existing cadence, but enforcing a strict "emergency bugfix window" of (say) 2 weeks after the release, and beyond that point we defer any fixes to the next full release.

[uranusjr]

Otherwise, we're increasing the commitment required from our RMs (being available to handle bugfix releases for the whole inter-release period) and that might end up actually making it harder to get RMs.

Would having an automated cherry-picking service (a la Miss Islington) help?

[pfmoore]

Not for me. I'm generally mildly uncomfortable with automated services like that, and they don't handle merge conflicts, so there's still work involved.

Please understand, I have no objection if others are in favour of having a bugfix branch that runs for the life of a "main" release (and what tools we use to manage that should be decided by the people willing to be RM). But I'd be unlikely to be able to volunteer as RM if I had to commit to managing the release through a 6 or 12 month period, whereas I'm fine with the current commitment of "do a release, and keep an eye on it for a week or two".

[sbidoul]

I'd be in favor of keeping the existing release cadence while doing less bugfix releases.

My reasoning is that the packaging ecosystem is evolving quickly and pip plays an important role in that evolution.
Slowing the release cadence now could, I think, also slow down adoption of modern practices. Either because new pip features take longer to be available, or because deprecation of old practices take longer to become visible.

[pradyunsg]

I agree that slowing down our release cadence would be harmful to the adoption and evolution story. Let's not do that. :)

releases are oddly timed for the Python 3.X.0 releases, with the annual cadence.

The best thing that I can think of here, is that we declare compatibility with the upcoming Python release in the YY.2 releases. Those releases will basically come out during the beta phrase for the CPython release, and it should be fine to let CPython have something that's ~2 months old at the time of the main release.

I'm fine with the current commitment of "do a release, and keep an eye on it for a week or two".

Yea, and I think this is the right approach for us.

---

I'm coming to the conclusion that we should maintain status quo, except for adding the Python 3.11 support classifier in time for the 22.2 (July 2022) release. Does that sound reasonable to everyone?

[uranusjr]

The best thing that I can think of here, is that we declare compatibility with the upcoming Python release in the YY.2 releases. Those releases will basically come out during the beta phrase for the CPython release, and it should be fine to let CPython have something that's ~2 months old at the time of the main release.

Since both the beta and rc cool down are ~1 month, the two month periods makes the pip release falls very closely to the beta-rc transition, which is a bit awkward since pip usually would want to release at least one bugfix, which would happen during rc. So I feel a three months period (or at least 2.5) would be more appropriate, and we either need to change our habit ans starting to do a scheduled release very early in the month instead, or push the release one month sooner (i.e. March, June, September, December) to account for our habit to release before the month ends[1].

[1]: 19.2 was released on the 23th; 20.2 was 29th; 21.2 was 24th.

[uranusjr]

Pradyun and I discussed the release cadence briefly during PyCon US (remotely). Since CPython now does a stable yearly cadence, we should adjust our cadence so people have a chance to test how pip interacts with packaging-related changes during CPython’s alpha phase (e.g. sysconfig and importlib.metadata).

3.11.0 beta 1 happened on 2022-05-08, and 3.12 should follow a similar schedule. So if we move pip’s schedule one month back (i.e. Feb, May, Aug, Nov), pip x.0 would serve as the testing ground to gauge how changes in CPython would affect pip, and be fixed in time for the beta.

I would love to hear how everyone thinks of this.

[pfmoore]

Seems reasonable to me. 3.11 final will be in early October, so we'd be putting the August release of pip into ensurepip for the final release, and it would give us 2 months to make sure it's solid. Conversely, ensurepip would start providing an "old" version of pip only 1 month after release. Are we OK with that? (Personally, I don't have a problem with it, but repackagers may have schedules they'd want to match up with).

[uranusjr]

Conversely, ensurepip would start providing an "old" version of pip only 1 month after release.

This was also brought up briefly during the discussion. This is a practical compromise between stability and up-to-date-ness for pip maintainers, and since any pip version would become outdated in three months time—which is very short compared to a Python version’s lifetime—anyway, this is likely an acceptable choice. Repackagers may have different opinions, of course, but they can always choose their own scheme. I believe at least Debian and Red Hat already do, and most repackagers tend to be happy to follow one of their policies.

[di]

except for adding the Python 3.11 support classifier in time for the 22.2 (July 2022) release

Is there a reason this didn't happen? I can't find any other related discussion.

[pfmoore]

Probably mostly just a combination of "we forgot" and "it doesn't actually have any practical impact so it's easy for us to forget" 🙂 Is there any practical impact of not having the 3.11 classifier?

I've created #11283 so we don't forget again.

[di]

No practical impact in terms of this project or publication, but for downstream users, this is the best indicator we've got that Python 3.11 should be considered supported by pip. Thanks!

[pradyunsg]

The answer was no. :)