Desired release schedule?

[native-api]

So far, we have been releaseing about once a month. This is an arbitrary number which supposedly puts acceptable strain on us -- but does not necessarily meet our users' needs.

As such, we'd like to hereby collect feedback on what our users' needs regarding release schedule are -- and/or which schedules would meet them.

It is possible to automate creating releases with Github Actions to make them more often -- but we need to know when exactly to do that.

E.g.:

• Do we need to make releases at all? Would just using a branch head work?
• Monthly?
• Weekly?
• ASAP after a CPython (pre)release?
• ASAP after any Python flavor release?
• After any bugfix?
• After any behavior change?
• After any change whatsoever?
• Something else?

[DavidCain]

Thank you so much for starting this discussion!

Having pyenv releases made available shortly after security releases to CPython are announced would be extremely helpful.

[native-api]

What does qualify as a "security" release? A release with a "security" section in release notes? A release on a branch in the "security" support state?

[gg-kialo]

I would take that as meaning after any patch version release. CPython are quite good at sticking to a pre-published release schedule - https://peps.python.org/pep-0693/#bugfix-releases.

It's been two weeks since the latest 3.12.3 release, and that's not included in a release of pyenv yet. This is causing issues since my pyenv is tracking master, but other people on my team are installing from homebrew, so I've broken their environment by specifying a python version that they can't install yet. If pyenv releases followed the cpython releases then this would be a lot less painful.

[ViktorHaag]

I believe that brew users can install the package in a way that allows them to also track HEAD instead of releases, but whether you want to recommend that as a practice is a good question and something to consider.

[JanMalte]

I would prefer to get a new release shortly after any Python flavor release?
We use pyenv for our CI/CD and use renovate to update our environments.

[andrefreitas]

In our organization, we try to keep up with the latest Python stable versions.

It's easy to change our Dockerfile versions but then developers need to use pyenv for managing the Python version needed for VSCode and other editors. This gap between an official release and availability on pyenv is not ideal.

We shouldn't put more pressure on contributors, this should be automated. Since we have seen contributors keeping Python versions up to date with PRs on this repo or we ourselves can also contribute, the problem I believe should be solved is automating releases.

Anyway, this workaround I've found now brew install pyenv --head is good enough for us.

Thanks for being open to discuss this.

[ViktorHaag]

Thanks for maintaining this great utility, and for facilitating this discussion!

Is it possible to consider a release schedule that's not monotonic, but allows for releases after different kinds of things: like a PR that simply adds a new version of an interpreter that's been released by the upstream team (like CPython or PyPy), and passes the pyenv test suite could trigger a more immediate new release, but releases including other kinds of changes could happen on a slower more deliberate schedule?

[native-api]

Thank you all who participated!

• There's a clear consensus that:
  • we need to release ASAP after a CPython release
  • and (perhaps with a little less priority) another flavor's release as well
• There isn't a strong urge to release other changes (bugfixes and features) on a deadline, just somewhat regularly
  • Given that upstream releases are done quite often, I don't think we need a separate schedule for them if we keep releasing the master branch as we do now. If that changes, we can always discuss that separately.

We'll implement automatically making releases first, and will gradually automate adding new versions as well for different flavors.
The generator scripts will still need occasional maintenance as the required script logic changes, but we'll figure out something to detect such cases.