Feature request: provide a way for "pyenv update" to consider only (stable) releases

[bersbersbers]

As far as I understand https://github.com/pyenv/pyenv-update/blob/master/bin/pyenv-update, what it does is just update all of pyenv to the most recent commit of the master branch.

Given the recent confusion about changes introduced with v2.0.0, I would have loved to skip all intermediate updates until v2.0.0 was actually released. Is there a way to do that? I would be fine with just jumping from release to release (and maybe cherry-pick a commit from time to time to build a newly released Python).

It seems one can use $PYENV_BRANCH to switch to (or at least stay on) one particular branch, but that variable is not documented as far as I can see, and I have no idea which branch would be suited for this.

[bersbersbers]

Another option is just checkout the latest tag, like so:

git fetch --tags && git checkout $(git describe --tags $(git rev-list --tags --max-count=1))

Reference: https://stackoverflow.com/q/17414104/#comment84339741_22857288

This may include release candidates such as https://github.com/pyenv/pyenv/releases/tag/v2.0.0-rc1, but some more sophisticated filtering of git rev-list --tags should solve that.

[native-api]

Updating to the latest tag is possible. It wouldn't have saved you from the breakage caused by 2.0.0 though since that was an intentional breaking change.

[native-api]

It wouldn't have saved you from the breakage caused by 2.0.0 though

As such, I don't see what this would achieve. We keep master stable and just slap tags on it once a month -- so there's no real benefit to updating to the latest tag rather than branch head.

[bersbersbers]

It wouldn't have saved you from the breakage caused by 2.0.0 though

As such, I don't see what this would achieve. We keep master stable and just slap tags on it once a month -- so there's no real benefit to updating to the latest tag rather than branch head.

Well, I would have at least avoided breaking changes until they were actually released, announced, discussed, met by other non-dev users, had workarounds proposed etc.

In addition, I think there was some back and forth on master, so in effect, while master was stable in and of itself, I remember going through several breaking changes in a row, instead of only once when they were released.