Removing "v" prefix from the tag is intentional?

[umireon]

The releasing script under .github was changed to accept only the tag without "v" prefix (e.g. 1.0.0) though the previous script accept the tag with "v" prefix (e.g. v1.0.0).
Changing the tag specification is very confusing and I want to ask whether this change is expected and why this change is necessary.

Operating System Info

macOS 13

Other OS

No response

OBS Studio Version

29.1.3

OBS Studio Version (Other)

No response

OBS Studio Log URL

OBS Studio Crash Log URL

No response

Expected Behavior

Current Behavior

Steps to Reproduce

Anything else we should know?

No response

[PatTheMav]

It is good practise to use semantic versioning for git tags when tags are also used for releases. This enables direct use of the git tag (and output of git describe) with other tools or systems that expect a semantic version number.

A single-letter prefix breaks the semantic standard and we opted to be compliant with this moving forward.

[glikely]

I'm disappointed with the decision here. Agree that using semantic versioning is good practice, but it is very common practice for those tags to be prefixed with 'v' (i.e., Linux kernel). The schematic versioning standard even references that usage.

My own plugin project uses 'v' prefixed tags, and this complicates matters for me.

Is “v1.2.3” a semantic version?

No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

[PatTheMav]

You are free to change this and use different standards for your own plugin. The template does not enforce rules or is itself mandatory to be used - it's merely a starting point for new plugins, but we fully expect developers to adapt, change, and otherwise shape the code contained in the plugin to their needs.

(Template repositories are literally just intended to create new repositories, but there is neither the expectation nor promise that updates to the template can be cleanly merged into repositories created with it in the past: https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-template-repository).