Naming change from `v4.x.y` to `Release 5.x.y` breaks some package management in the wild.

[divinerites]

Describe the bug

First a great thank you for your work. Really helpfull.

• Since version 5.x.x, the release name is no more v4.x.y but Release 5.x.y.
• This breaks any tool based on the official semantic versioning naming because it miss the leading v.
• In my case it is Go (and gohugo.io) modules, and by default the latest "visible" package is v4.7.0.

I don't know the reason for naming Release 5.x.y and if it can be back to semantic versioning v5.x.y in the future.

To Reproduce

• $ go mod get github.com/FortAwesome/Font-Awesome
• We get the v4.7.0 (the latest with correct semantic versioning)

Expected behavior

If i ask for a v5 specific version, it works.

• $ go mod get github.com/FortAwesome/Font-Awesome@5.15.1
• We get the right latest v5.15.1

Bug report checklist

• [x] I have filled out as much of the above information as I can
• [x] I have included a test case because my odds go way up that the team can fix this when I do
• [x] I have searched for existing issues and to the best of my knowledge this is not a duplicate.

Seems related to https://github.com/FortAwesome/Font-Awesome/issues/16926

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community and thanks for reporting this.

I can confirm. Also, there are some tags without v even in older versions (e.g.: 4.1.0, 2.0.0)

This breaks any tool based on the official semantic versioning naming because it miss the leading v.

I think Semantic Versioning is preserved, because the v prefix is not part of the version.

Quoting from: https://semver.org/#is-v123-a-semantic-version

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”.

(emphasis mine)

I would like to add v to the tags again and push, but this will break things and mess up with current tags/releases.

@robmadole what should we do? Start adding v again from the next release?

[robmadole]

@tagliala @divinerites this has actually come up recently talking about our next major release, 6.

As @tagliala mentioned the v is not part of the spec but obviously there are tools that are expecting it. I'm not inclined to change this for just one tool (the Go package manager). My concern is that if we start adding the v are we going to start breaking someone else?

What we've been wondering lately is if there is a wide-spread convention that says "most people use the v prefix". We're not opposed risking the backward-incompatible change but we need to have a good reason for it at this point.

[divinerites]

Yes, I understand well your concern about non breaking things for v5/v6 (the v4 had this v prefix).

But is seems to be common practice, and almost all packages I know on github in the npm area (and others) have this v prefix on their package release : ex 1, ex 2, etc...

Anyway thanks for having took the time to look at this.

[tagliala]

I've checked some of the most popular github repos and it looks like that the v suffix in tags is a common practice.

Popular repositories that do not use v suffix include:

• flutter
• vscode
• go (they use go prefix)
• angular

I do not have a clear position on this, I would say 66% break and go for v prefix in tags

[UtkarshVerma]

I like to use Hugo modules and this naming change for releases breaks it. If I try to fetch the latest release, I see the following:

$ hugo mod get
go: no module dependencies to download
hugo: downloading modules …
go: downloading github.com/FortAwesome/Font-Awesome v4.7.0+incompatible
go: added github.com/FortAwesome/Font-Awesome v4.7.0+incompatible
hugo: collected modules in 22807 ms

It fetches v4.7.0 because apparently, that is how go get works. It would be great if semantic versioning was picked up again.

[rhcarvalho]

A workaround for the Hugo usage is to manually update go.mod to specific a branch/tag/commit/etc.

For example, to use the latest commit on the 6.x branch, update go.mod:

require (
    github.com/FortAwesome/Font-Awesome 6.x // indirect
)

Then run hugo mod tidy, and it will update the go.mod file to something like this, a reference to the latest commit:

require (
    github.com/FortAwesome/Font-Awesome v0.0.0-20230327165841-0698449d50f2 // indirect
)