Shields: Leading "v" is forcefully added in github release badges

[tooomm]

Example:
It's a badge for this release on GitHub.
But the release tag there is 2017-05-05-Release-2.3.17 without v.

I understand that if you use straight semantic versioning for tags you are mostly ok.
Though, there are different recommendations on the usage of "v1.0" or "1.0".

[paulmelnikow]

Yea, that doesn't look great.

Some options:

1. We could also add a flag to control whether the v prefix is there or not.
2. We could leave off the v all the time.
3. We could write a function which detects versions which look strange with a v prefix, e.g. which start with a date.

There was a discussion years ago about 2, and the v seemed slightly preferable; don't feel a need to change that now. Since our aim is to provide consistent badges to users, I like to avoid configuration where possible, so I'd lean toward the last option. If we identify other formats which are less legible with the v prefix, we can easily add them. Option 3 is also easier to implement.

[tooomm]

We could also add a flag to control whether the v prefix is there or not.

I like that a lot.
I understand that more options could lead to less consistency, but anybody could just start using a v2.3.4 tag over 2.3.4 to archive the same... if you consider the v showing or hiding as inconsistency.
Or do you remove any leading v from tags (or check before inserting one) to prevent release | vv2.3.4?
As long as there is a solid default without flag it shouldn't be too bad at all?

We could write a function which detects versions which look strange with a v prefix, e.g. which start with a date.

Also a consideration. As a start, check could be if "tag = valid x.y.z semver" and add a "v" in that case. Otherwise don't?

[paulmelnikow]

As long as there is a solid default without flag it shouldn't be too bad at all?

That's our aim.

I wouldn't want to push projects to change their tags. Since tags with and without v's are both in common use, and supported by many tools, Shields' job is not to encourage one convention or another. Rather we should paper over the inconsistencies between projects.

As a start, check could be if "tag = valid x.y.z semver" and add a "v" in that case. Otherwise don't?

Some folks use version schemes which are not valid semver like 1.0 or 1.1.1.1, which look fine with a v. So, to be on the safe side, I'd probably start by approaching this the other way, and matching version types that look terrible with a v. For example, anything that starts with a xxxx-yy-zz, which is clearly a date, or anything which does not start with a number.

Are there examples of other projects with version number schemes that look bad with the v?

[tooomm]

Some folks use version schemes which are not valid semver like 1.0 or 1.1.1.1

Sure, not all projects use semver. No idea what made me belive that. :D

I'd probably start by approaching this the other way, and matching version types that look terrible with a v. For example, anything that starts with a xxxx-yy-zz, which is clearly a date, or anything which does not start with a number.

Are there examples of other projects with version number schemes that look bad with the v?

Those two seems totally valid and catch a lot of cases.
Basically all tags not starting with numbers would look weird and don't want the v.
Same for special characters.
Regarding numbers it should be a version number or date. I could imagine a git hash or something as well, or some kind of build number. Both seem less likely though.

[paulmelnikow]

Looks like we already have a function which does this, so we'd need to tweak it and add tests. A unit test in color-formatters.spec.js seems sufficient.

Ideally we'd also make sure we're calling that function everywhere. I see a few places like here where we aren't. Anywhere we change badge code, the badge should get a service test if it doesn't already have one.

Would you like to make a PR?

[tooomm]

I would happily contribute lines to help with badges for this cool project, but I'm more on the non-code side of things...
Somebody else need to step in here.

But with your findings and help, I hope that somebody else likes to tackle that. 👍

[RedSparr0w]

Maybe we could add a global query param ?prefix=myprefix which is available to all badges.
The version formatting could then possibly be updated so it adds the v as a prefix which could then be overridden via ?prefix=.

Thoughts on this?

[paulmelnikow]

In this case, I don't see a need for this to be configurable. Since our aim is to provide consistent badges to users, the less configuration we have, the better.

[PyvesB]

I've started to draft some things for this piece of work, hope that's okay!