More flexible bugfix releases

[JukkaL]

Currently the release manager for a feature release is expected to decide if one or more bugfix releases should be released and to publish them (e.g. 0.982 if 0.981 is the initial feature release). It was suggested in the 1.0 release planning meeting earlier this week that there's no compelling reason why this needs to be always performed by the release manager.

My proposal is that we could have at least one or two additional people (who already have commit access) who can publish bugfix releases. The minimal requirements to make this feasible would be to give them upload access to our PyPI project and to document the process.

Here's a suggested process:

• Anybody who has been onboarded to the process (this includes all release managers and others with PyPI upload access) can volunteer to publish a new bugfix release by leaving a comment on the release planning GitHub issue with the suggested list of fixes to include.
• If there are no concerns, the release can be uploaded the following day by the volunteer. (It's probably best to avoid publishing releases over the weekend, unless there is a big regression.)
• Anybody can suggest additional bug fixes to include, and the volunteer can decide whether to include them.
• If the changes seem significant enough, the RM for the feature release can choose to take over. This could happen if e.g. a separate blog post should be written. I'd expect this to be rare, but it can make sense occasionally if there are major regressions.

Open questions:

• Should we allow releasing bug fixes to older releases (e.g. releasing 1.0.2 if 1.1.0 is already out)?
• Should this be only limited to regressions, or could we release arbitrary (low-risk) bug fixes?
• Where should we document this process? In the wiki?
• Would there be a limit on how frequently we'd make bugfix releases? The above process would limit bugfix releases to at most one per day, but that is already much more frequent than what we've traditionally had (typically at most one bugfix release per feature release).

Rationale:

• This would make it possible for additional contributors to help with the release process, which has been a bottleneck. Currently all release managers are Dropbox employees so that they can access Dropbox internal codebases, which has been helpful in finding additional regressions. Publishing bugfix releases doesn't require access to internal codebases.
• If the main release manager is on vacation, for example, or otherwise busy, we have sometimes had regressions go unfixed for a long time, and this could help with this.

Please let me know what you think about this, and if you'd like to help with making bugfix releases.

cc @hauntsaninja

[hauntsaninja]

Yes, this sounds good and I'd like to help with this. I'm https://pypi.org/user/hauntsaninja/

I think things we should allow backporting are a) fixes for regressions or low risk fixes for bugs that make a new feature less usable, b) select low risk bug fixes that are individually worth releasing for, c) documentation changes relevant to the release, d) fixes for wheel builds.

Recent examples of things I'd have made a release for are the fixes for sys.path regressions in 0.970 #13089 (comment) and the fix for stub parsing issues surfaced by Python 3.10.7 #13627. I could try making a release for #13385 (comment)

Signs of the process not being used as intended include: more than a handful of changes are backported, running into merge conflicts when backporting, backported changes cause new mypy_primer errors, backported changes need their own documentation, backported changes not corresponding directly to new issues filed by users, including a typeshed sync, etc.

The wiki sounds good for documenting the process!

We shouldn't release bug fixes to older versions. That way lies madness. (It's also not that hard for users to just update to latest mypy; users typically have more control over updating dev tools than updating libraries)

[ilevkivskyi]

Should we allow releasing bug fixes to older releases (e.g. releasing 1.0.2 if 1.1.0 is already out)?

I think yes, as soon it is a low risk fix.

[JukkaL]

@hauntsaninja I just invited you to the mypy PyPI project.

About bug fixes to older releases: I think that we can reserve this for very serious issues (e.g. some use case is completely broken, lots of false negatives).

I still need to document the release process.

[hauntsaninja]

Thank you for the trust! Just accepted the invitation :-)

[JukkaL]

Here's my first attempt at documenting the release process, including making bugfix releases: https://github.com/python/mypy/wiki/Release-Process

All feedback is welcome!

[erictraut]

Looks like Jukka's proposal was adopted and documented. Is there anything remaining with this issue, or can it be closed?