feat: remove the v from version, to match ruff

[CoderJoshDK]

Since version 0.5, ruff has dropped the v in its version. This mirrors that.

As mentioned and done in astral-sh/uv-pre-commit#5, ruff no longer has v in its version. This PR removes it. This is an in between commit while I wait for approval of a bigger restructure.

This also undos #92. As mentioned there, the reason the link was wrong, was because of the de-sync between version semantics.

Important

After merging, manually create a new tag and version.

[CoderJoshDK]

Because I know this will take a while to get to, just let me know when (or if) you are going to merge this. Because it also requires the change of the README to work properly. (remove the V from the ever-changing version, so the regex picks it up). Well ... I could make the regex pick up the v "optionally" and drop it. But that feels wrong.

[GabDug]

Hey 👋!

I wanted to add my 2 cents on this change. Several projects that synchronise pre-commit hooks and locked versions use a mapping between PyPI packages and pre-commit repositories, with a default "database" and user-configured mappings. These mappings often include information on whether the tags for each repository include the v prefix. Introducing a different tag format for the same repository could create compatibility issues for these tools, as they behave in a more basic way than pre-commit autoupdate that was mentioned in #92.

While it is possible for tools to implement special handling for the specific cases of ruff and uv, I would advise against making this change or introducing both tag formats. Such changes could introduce unnecessary complexity and potential for errors, or require a manual user-configuration depending on the version used.

For reference, here are some examples of tools that would be affected:

• sync-pre-commit-lock, which I maintain
• sync_with_pdm by @floatingpurr
• sync_with_poetry by @floatingpurr

Have a great day!

[MichaReiser]

@GabDug thanks for the added perspective on this.

My concern with removing the v prefix is that this is also likely to break existing tools and workflows. For example, wouldn't it require your tool to use the mapping with the v prefix up to version 0.5, then without the v prefix up to 0.5.6, and then go back to the mapping with the v prefix for versions > 0.6.0