pre-commit autoupdate wrongly picks pre-releases like 1.2.3a0

[ssbarnea]

The semantic versioning spec from https://www.python.org/dev/peps/pep-0440/ documents versions like 1.2.3a0 as pre-releases and by default tools should not pick them unless the user explicitly wanted them.

A good example is pip which will never install pre-releases unless user is adding the --pre parameter.

I discovered that pre-commit autoupdate did pick ansible-lint prereleases which is clearly not something users may expect. I seen this happening on at least two other hooks and based on git tag inspection, I could say that there was nothing wrong weird on how the tags were added.

I think that, by default, pre-commit should skip non release suffixes like a, dev, b, rc.

[asottile]

pre-commit does not use semantic versioning or python versioning to determine the git tag to pick. It picks the latest tagged version on master

this is working as intended

[ssbarnea]

@asottile And do you not see this as a problem? I am asking because I want to know a PR that would address this feature/bug would be accepted. Probably it could be triggered by an extra config option named: rev-filter (regex configured). Clearly the latest tag is not always the stable one.

[asottile]

It's not intended to be a stable tag. Just latest version (and ideally not a hash). Trying to attach meaning to strings which may or may not be versions and may or may not be semantic is going to be a nightmare of edge cases.

I do see how this could be a concern, but it is doing exactly what I would want to do in this situation

[yajo]

How about allowing to specify a repo's version filter, based on standard schemas?

You can leverage https://versort.readthedocs.io/ to handle the logic beneath.

[asottile]

no thanks, at that point you'd have less effort to manually select your version

[ssbarnea]

@yajo While I was the one that opened the ticket long time ago, I have to agree that @asottile did the right call here. The benefits of keeping the logic simple and avoid adding extra complexity worth the price. I introduced/maintained pre-commit hooks on likely over 100 repos and some of them having ever 10 repos inside. I only got the auto-upgrade pick an undesired version twice. That is like once per year.

On the other hand it would be happy to see the github discussions features enabled on this repository, so we can ask questions and exchange experiences without risking improper use of the issue tracker.

[jepler]

Hi. Is there any sort of evidence that would allow you to draw a different conclusion about what is the desirable behavior here?