Why is 0f0ccba tagged with v1.32.0 as well as v1?

[jmartens]

@epage Why is 0f0ccba tagged with v1.32.0 as well as v1?

This is really confusing when running pre-commit autoupdate as the output of pre-commit seems to suggest it is downgrading:

# pre-commit auto-update
[https://github.com/pre-commit/pre-commit-hooks] already up to date!
...
[https://github.com/crate-ci/typos] updating v1.32.0 -> v1
...

[epage]

If you look at our commits, we have several tags we may apply to any given commit. In particular, a v1 tag can be helpful for github actions (see #857). However, pre-commit treats tags as immutable (which is generally a safe assumption).

The overall pre-commit auto-update problem is being discussed in #390.

[jmartens]

Hmm, so by honouring #857 you created a confusing mess for use in other tooling like pre-commit. I would suggest reverting this and rethinking this.

Suppose you in the future will have something like

⚪ 🏷️v1.x+n+1
⚪ 
...
⚪ 
⚪ 🏷️v.1.x+n, 🏷️v2
⚪ 
...
⚪ 
⚪ 🏷️v1.32.0, 🏷️v1
⚪ 
...
⚪ 
⚪ 🏷️v1.31.x
⚪ 
...

What would happen if you release a 🏷️v2 for github actions and are still on the 1.x range for you regular version scheme? I wonder if pre-commit never update past 🏷️v2 keeping me, and perhaps others as well, on a unintended pinned release? Or am I worrying unnecessarily?

[epage]

Worse: once you are using v1, that install of pre-commit is pinned to that exact commit, regardless of what new v1.x.y releases come out.

As I said, #390 is the issue for discussing this if you have something new to add.