-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maven badge has "v" prefix #3200
Comments
Hi! Thanks for the report. This is from https://github.com/reactor/BlockHound#getting-it and is probably what is confusing them: Maybe add something like "(without the 'v')" after these customized badges? Or if you want to keep those bullet points the way they're written, use a custom XML badge: https://img.shields.io/badge/dynamic/xml.svg?label=&color=blue&query=%2F%2Fmetadata%2Fversioning%2Fversions%2Fversion&url=https%3A%2F%2Frepo.spring.io%2Fmilestone%2Fio%2Fprojectreactor%2Ftools%2Fblockhound%2Fmaven-metadata.xml |
Hi @paulmelnikow, Wow, thank you, I didn't know there is such feature! I will use it for now, but would still appreciate the configurable prefix in future |
I hear you. Consistency is a project goal, so would prefer to avoid adding customization options unless there’s widespread need. As far as I know, this is the first time this has been requested. There are lots of ways to hack / customize for rare use cases. I understand your perspective may be different! |
@paulmelnikow, IMO adding the v prefix harms consistency. Consider a well-run project, with well-named tags, which match package manager release versions, etc., and happen not to use vs. Using shields.io in such a project introduces these vs, which are not consistent with anything else in the project, and that confuse users and readers of the project's README. Adding vs unconditionally enforces someone else's convention on otherwise quite clean projects. I am strongly in favor of passing version numbers through unmodified. I am not sure what the origin of adding the v prefix is, but it effectively penalizes projects that aim for consistency and do not use v, presumably in the interest of helping out projects where platform constraints or conventions make consistency impossible (but I don't know). I would love to use more shields.io badges in my projects (and maintain them manually less), but I can't have this v. I would really appreciate either not touching versions, or making this configurable :) |
Hi @aantron, you can probably use a workaround like the dynamic badge. Which badge / project is this about? I'm not convinced the prefix works against consistency. Few package managers use a |
This project, for example: https://github.com/ocsigen/lwt#readme Or any of the other projects pinned in my profile. I'd like to display the latest GitHub tag.
It's a convention about a design element :) And that design element creates inconsistency in projects that don't otherwise use it. If I were to use this kind of shields.io badge, I would sacrifice consistency within my projects (with changelogs, tags, commit messages), between my projects, and between my projects and the language communities I work in (their package managers' conventions, forum writing conventions, etc), for the sake of consistency across all projects that use shields.io. I don't see why the last one should be preferable. Why shouldn't each project decide how their version numbers should be displayed? Don't the projects know best how to achieve the consistency that they need? Isn't the best way to do this by simply exposing the version numbers of the underlying system, such as GitHub or a package manager, and keeping shields.io out of the way? Why should there be a global default, affecting these strings? I imagine there is a legitimate worry about different APIs reporting version numbers with Just prodding with questions :) |
I can see that the |
You can read a little bit about how Shields was started here: https://olivierlacan.com/posts/an-open-source-rage-diamond/ The idea behind consistency provided by Shields is to provide less choice, not more, and broadly encourage consistency across projects. We're not here to force anyone to do anything, though this goal means we have to say "no" to things. That said…
That makes sense about the label. Most of the package manager badges use the name of the package manager as a label, though we have a couple, like for package.json and tag that don't. I agree it doesn't make a lot of sense to prepend a prefix on a tag badge, where it then becomes ambiguous whether the |
Yes, agreed. The last point is especially relevant if someone (me :p) has named their badge "version," so they get... My vote is for leaving the Edit: and it's backwards-compatible with the current behavior :) |
Or, another way to say it, the alternative usage would be a very welcome escape hatch of sorts. |
So what's the thinking here for resolution? A new query param on the maven badge that a user could include to not add the I.e. something like Or is this not something we'd be able to support for the reasons articulated above? |
I suppose it would be some query param, but potentially supported on all version badges. The fact that it's available doesn't have to be documented on every version badge generator, but probably should be documented at least on the GitHub release badge generator. I don't know what's easiest here. I'm also ok with not documenting it at all :) |
In the interest of providing good defaults, I'm 👍 on removing the prefix from the GitHub tag badge. To be honest, I don't think it should ever be added, because if you see tag | v9.0.0 you don't know whether the tag actually has a Still in two minds about the release badge; want to think a little more about that one. As a design element the It occurs to me that perhaps we should develop a bit more process around design decisions, and maybe institute some kind of RFC process to make that process more accessible! |
@paulmelnikow This sounds good :) I want to add one more data point. For example, I would want to use the NPM version badge in one of my projects (https://github.com/aantron/repromise#readme), to keep the version number synced, but rename the label to In fact, the |
In light of the last couple comments, could you please reopen this issue? Alternatively, I can summarize them in a new one. |
@paulmelnikow I'm all about consistency, and I would actually favor consistency within projects (between their badges, their doc and their tags) over consistency between badges of unrelated technologies. Like @aantron, this badge is the only place in my projects where the version is prefixed with a
Isn't this true for all version-related badges? Some package managers have no particular constraint on the version format and the |
Closing and locking this thread given the age of the thread with provided context, and refer folks to the discussion in #6135. Please note that we consider the matter closed as well, and we're not going to remove the |
Are you experiencing an issue with...
🪲 Description
The Maven metadata badges are automatically prefixed with "v" and it is misleading the users
🔗 Link to the badge

💡 Possible Solution
Remove it, or make it configurable
The text was updated successfully, but these errors were encountered: