More specific node version badge? #308

Martii · 2014-11-17T05:19:28Z

Is it possible to get a full version of node.js in a badge? ~~Currently I'm looking at with 0.10.x... which is better than nothing... but~~ it would be nice to see the .33 that it is currently on.

Thanks in advance and I love these little things... nice work. :)

The text was updated successfully, but these errors were encountered:

espadrine · 2014-11-17T13:57:02Z

Thanks for this feedback!

Given the current implementation of node badges (its color giving an indication of whether it supports the latest node version), it will be fairly easy to implement that. What do you think the path should be? /node/ve/….svg, for "exact version"?

Martii · 2014-11-17T16:45:46Z

What do you think the path should be? /node/ve/….svg, for "exact version"?

I'm not entirely sure on that one... I am not quite sure why this is the only badge that we use that doesn't have the exact so... maybe perhaps nodejs if you want to make it different than node ?

espadrine · 2014-11-17T18:00:40Z

That's a fair point. What is displayed is the semver version range, instead of a specific version. Perhaps, to stay consistent, we can have /node/v/ stand for the exact version, and /node/vr/ stand for the version range.

I fear that having both /node/ and /nodejs/ will become confusing.

dougwilson · 2014-12-11T05:58:33Z

Hm, it would really suck if the behavior of the current badge URLs changed... Originally I asked for this badge because I want to show the semver range, as in "hey, this module works with >= 0.10". Really, showing the exact version doesn't make any sense, because it's not a badge just to show whatever the latest version of Node.js its out, but rather what versions of Node.js your module is compatible with.

Martii · 2014-12-11T06:22:12Z

I fear that having both /node/ and /nodejs/ will become confusing.

Looking back in older node releases it used to be called nodejs too. Having both types would be good for both use cases (dispersed dependency check to see if a project is out of date in development versus production as compared to eye-candy for a range of support) especially for those classicly glued to it's original use. The 0.10.x can easily be checked in a projects compatibility with the engines named key. As it sits now the 0.10.x isn't accurate for those specifying something like a semver of "node": ">=0.10.33". The naming of the URI route/path is just the hard part I think. :)

dougwilson · 2014-12-11T15:20:27Z

As it sits now the 0.10.x isn't accurate for those specifying something like a semver of "node": ">=0.10.33".

So... "0.10.x" is a semver range. It expands to >= 0.10.0 < 0.11. I mean, the badge just reflects whatever the author of the package choose to use. If the author only wanted their package to be installable on Node.js 0.10 (and not 0.9, nor 0.11), that's up to the author.

Besides, replacing the badge to list whatever the latest stable version of Node.js that fits in the rage is not useful here. I use the badge all over my projects, which have their node engine set to >= 0.8 or >= 0.6; having those badges suddenly read 0.10.33 would be absolutely useless.

@Martii you can ask for a new badge for this, please, just don't alter the one that already exists.

Martii · 2014-12-11T15:57:09Z

@Martii you can ask for a new badge for this, please, just don't alter the one that already exists.

@dougwilson

Is it possible to get a full version of node.js in a badge?

... maybe perhaps nodejs if you want to make it different than node ?

e.g. you are asking the wrong person here and may want to give my responses another go around please. :)

Besides, replacing the badge to list whatever the latest stable version of Node.js that fits in the ra_(n)_ge is not useful here

That's precisely what the current node badge does... so you just stated it wasn't useful. ;)

@espadrine

... eye-candy for a range of support ...

In regards to this... if there were a generic badge that someone could send the strings out in the URI and have it customized that would solve the eye-candy bit for those who needed that. e.g. perhaps something along the lines of http://img.shields.io/custom/node/0.10.x.svg could generate the text of node on the left and the 0.10.x on the right. (another generalized example http://img.shields.io/custom/foo/0.7.x.svg would gen a foo on the left and the 0.7.x on the right). I don't know how the colors would come into play but just a thought.

dougwilson · 2014-12-11T16:05:17Z

Besides, replacing the badge to list whatever the latest stable version of Node.js that fits in the ra(n)ge is not useful here

That's precisely what the current node badge does... so you just stated it wasn't useful. ;)

No, it's not what the current badge does. Here is my version badge from a project: It doesn't do anything with the current version of Node.js, just echos my node engine semver range from my package.json.

dougwilson · 2014-12-11T16:11:45Z

The badge you have in your original post is displaying the engines value from the npm package gh-badges (https://www.npmjs.com/package/gh-badges), which they have set to 0.10.x. Why are you displaying the version of Node.js the gh-badges module works with on https://github.com/Martii/OpenUserJS.org ?

Martii · 2014-12-11T16:16:10Z

Why are you displaying the version of Node.js the gh-badges

That's what I'm looking into right now. The URI format isn't exactly documented so a lot was copy/paste and trying to figure things out by trial and error... in this case what you are saying is err. :)

That's nice that a shield route can read the package.json but it will still be nice to have a more specific node.js badge that actually validates against the current release of node as I mentioned in the very first post.

dougwilson · 2014-12-11T16:16:20Z

Basically to boil it down for you, the URL http://img.shields.io/node/v/<npmpackage>.svg displays the value of the engines spec in the npm package <npmpackage>'s package.json.

For example, if I put in etag, this is the Node.js badge for the npm etag module:
If it put in gh-badges, this is the Node.js badge for the gh-badges module:

The URL http://img.shields.io/node/v/<npmpackage>.svg has nothing to do with displaying what version of Node.js is out.

dougwilson · 2014-12-11T16:17:08Z

That's what I'm looking into right now. The URI format isn't exactly documented so a lot was copy/paste and trying to figure things out by trial and error... in this case what you are saying is err. :)

You're displaying a badge for the gh-badges project, not your project or even the Node.js project....

dougwilson · 2014-12-11T16:20:24Z

That's nice that a shield route can read the package.json but it will still be nice to have a more specific node.js badge that actually validates against the current release of node as I mentioned in the very first post.

Right. I'm just trying to say it's something that would be completely different from the URL http://img.shields.io/node/v/<npmpackage>.svg, since that is for displaying the version of Node.js a npm package works against. You're asking for something completely new: a badge that shows what the latest stable version of Node.js is. Yes, there is no such badge as this.

Node.js is not published anywhere, The only URL that would make sense to put your request under would be http://img.shields.io/node.svg

espadrine · 2014-12-11T16:24:59Z

@Martii

if there were a generic badge that someone could send the strings out in the URI and have it customized that would solve the eye-candy bit for those who needed that. e.g. perhaps something along the lines of http://img.shields.io/custom/node/0.10.x.svg could generate the text of node on the left and the 0.10.x on the right. (another generalized example http://img.shields.io/custom/foo/0.7.x.svg would gen a foo on the left and the 0.7.x on the right). I don't know how the colors would come into play but just a thought.

Are you looking for something like http://img.shields.io/badge/node-0.10.x-brightgreen.svg?

You have more information about this at the bottom of the website, shields.io.

espadrine · 2014-12-11T16:29:31Z

I don't intend on changing the semantics of http://img.shields.io/node/v/<npmpackage>.svg.

The color of the badge indicates whether the latest node version is supported. Green means yes.

Is there a use-case this doesn't cover?

Martii · 2014-12-11T16:32:14Z

Node.js is not published anywhere...

Confirmed... which is why it would useful for our project to have a route validate against https://nodejs.org or even their GitHub branch of 0.10.x to see what the latest stable is. Our project should never be published on npmjs.org so I don't think we'd ever have a badge.

Are you looking for something like ...

http://img.shields.io/badge/node-0.10.33-brightgreen.svg appears to work but that doesn't seem to validate against node branch e.g. we have to specify it to be 0.10.33.

dougwilson · 2014-12-11T16:32:16Z

I don't intend on changing the semantics of http://img.shields.io/node/v/.svg.

Cool, that's what I was scared about.

Is there a use-case this doesn't cover?

So, I figured out what @Martii wants: not a badge that shows what version of Node.js a npm module is compatible with, but rather a badge that literally just shows what the latest version of Node.js is out, nothing to do with npm modules.

Martii · 2014-12-11T16:34:16Z

but rather a badge that literally just shows what the latest version of Node.js is out

Yes... which leads back to my initial post even though I was using a package reference with the image... striking out shortly.

dougwilson · 2014-12-11T16:37:49Z

Hm, sadly the Node.js GitHub project doesn't uses GitHub releases otherwise you could use https://img.shields.io/github/release/joyent/node.svg

From looking over the different sources supported, it would mean the Node.js badge @Martii is looking for would be some kind of one-off thing; a badge that only does one thing: displays the latest version of Node.js from http://nodejs.org/dist/latest/SHASUMS.txt

Martii · 2014-12-11T16:41:14Z

... the Node.js GitHub project doesn't uses GitHub releases ...

They don't?

GrahamCampbell · 2014-12-11T16:41:56Z

No they don't. They use tags. That's different.

espadrine · 2014-12-11T16:45:54Z

What I use to fetch the latest node version is http://nodejs.org/dist/latest/SHASUMS.txt. It produces either a green color if the latest version is supported, or a yellow color if it isn't.

If you want, I can make a badge, say, /node/latest.svg, whose sole purpose is to show the latest node version released. I don't see the point, but I can do it. Of course, this may become obsolete very soon due to the fork.

Martii · 2014-12-11T16:50:11Z

The color of the badge indicates whether the latest node version is supported. Green means yes.

So we have a bunch of orange and blue on the other packages... but I know that all of them are supported in the latest stable release of node... did I miss the point here again?

espadrine · 2014-12-11T17:03:38Z

@Martii The badges shown here are npm: they show the exact npm version of those packages, not the supported node version range. Orange means "initial development" in the semver definition.

Martii · 2014-12-11T17:16:06Z

@espadrine
ahh okay then that explains that tangent. Thanks for these explanations. I did read all documentation but it was still a bit vague in my mind on some of the discussed things here. :)

So showing the exact node stable release badge would be a kewl addition ... I am gathering that this doesn't exist yet from all these replies.

I'm also contemplating making a user.js to read in our package.json and display those along side with npm's release versions just as an automatic visual cue check... basically what David does externally but instant/ondemand instead of delayed/watched... and what I do manually daily.

espadrine · 2014-12-11T17:23:08Z

I suggest http://img.shields.io/node/latest-version.svg then.

Martii · 2014-12-11T17:27:24Z

@espadrine

I suggest http://img.shields.io/node/latest-version.svg then.

So does that exist? ... or are you suggesting the new route?

Currently get:

<title>These aren't the pages you're looking for</title>
I have nothing to offer for this request

… but blood, toil, tears and sweat.

Fortunately, the main page can offer rainbows instead!
(You probably landed on this page because a link was broken, because someone mistyped its URL, or because of an irrelevant mistake. Don't worry, though: there is all of the rest of the Web to explore!)

btw LOL ;)

Martii · 2014-12-11T17:31:37Z

Just a sidenote too nodejs is above 0.10.x but not in stable though... so not sure if "latest-version" would be accurate enough... e.g. "latest-stable" might be better I think.

espadrine · 2014-12-11T17:35:23Z

iojs will start going the semver way, so there is no stable version yet.

danday74 · 2017-07-22T13:47:17Z

Since no-one has covered this here the format for engines in package.json is ...

"engines": {
"node": ">= 0.6"
}

when using ...

https://img.shields.io/node/v/<YOUR_PACKAGE>.svg

Martii · 2017-07-22T18:03:05Z

package.json may not always be on npmjs.com ... which is a related issue. The private bit may be set in which case it won't be on npmjs.com
More dynamic detection of a specific latest version, say 6.x, showing the latest version there is what is needed as alluded to with the engines property in the prior reply.

It's okay if it doesn't get done as the syntax was already mentioned as not changing... although another virtual field/parameter could be possible perhaps with the example of http://img.shields.io/badge/node-v0.10.33-orange.svg becoming http://img.shields.io/badge/node-v0.10.latest-orange.svg which could show the last (latest) version of that node version. e.g. a buzz word of latest invoking some process of finding it. In our case we would need in our README.md a value of something like http://img.shields.io/badge/node-v6.0.latest-orange.svg. As it sits right now we go visit https://nodejs.org/en/docs/ and see what it is with a click through.

paulmelnikow · 2017-10-13T15:06:11Z

Think this should be resolved by our existing node version support, updated in #1144, and our badge which pulls data from package.json on github, added in #739.

If there's something further we should do, would someone please open a new issue?

Martii · 2017-10-13T18:31:59Z

Examples taken from:

Rendered:

hmm... now I'm confused.

paulmelnikow · 2017-10-13T18:40:31Z

That PR is waiting for deploy. To see when that happens, you can keep an eye on https://github.com/badges/shields/tree/gh-pages.

I just pushed the latest to the staging server:

The server doesn't have the right font installed which is why the letter spacing is off.

paulmelnikow added the service-badge New or updated service badge label Apr 18, 2017

paulmelnikow mentioned this issue Sep 24, 2017

[Github] Github manifest/package.json version support #739

Merged

paulmelnikow closed this as completed Oct 13, 2017

Richienb mentioned this issue Feb 24, 2021

[Snyk] Upgrade fast-xml-parser from 3.12.10 to 3.17.6 Richienb/shields#9

Closed

snyk-bot mentioned this issue Apr 7, 2021

[Snyk] Upgrade fast-xml-parser from 3.17.4 to 3.19.0 pmutale/shields#5

Open

snyk-bot mentioned this issue May 28, 2021

[Snyk] Upgrade fast-xml-parser from 3.14.0 to 3.19.0 andruszd/shields#4

Merged

snyk-bot mentioned this issue Aug 15, 2021

[Snyk] Upgrade fast-xml-parser from 3.12.10 to 3.19.0 Richienb/shields#17

Open

More specific node version badge? #308

More specific node version badge? #308

Comments

Martii commented Nov 17, 2014

espadrine commented Nov 17, 2014

Martii commented Nov 17, 2014

espadrine commented Nov 17, 2014

dougwilson commented Dec 11, 2014

Martii commented Dec 11, 2014

dougwilson commented Dec 11, 2014

Martii commented Dec 11, 2014

dougwilson commented Dec 11, 2014

dougwilson commented Dec 11, 2014

Martii commented Dec 11, 2014

dougwilson commented Dec 11, 2014

dougwilson commented Dec 11, 2014

dougwilson commented Dec 11, 2014

espadrine commented Dec 11, 2014

espadrine commented Dec 11, 2014

Martii commented Dec 11, 2014

dougwilson commented Dec 11, 2014

Martii commented Dec 11, 2014

dougwilson commented Dec 11, 2014

Martii commented Dec 11, 2014

GrahamCampbell commented Dec 11, 2014

espadrine commented Dec 11, 2014

Martii commented Dec 11, 2014

espadrine commented Dec 11, 2014

Martii commented Dec 11, 2014

espadrine commented Dec 11, 2014

Martii commented Dec 11, 2014

I have nothing to offer for this request

Martii commented Dec 11, 2014

espadrine commented Dec 11, 2014

danday74 commented Jul 22, 2017 • edited Loading

Martii commented Jul 22, 2017

paulmelnikow commented Oct 13, 2017

Martii commented Oct 13, 2017

paulmelnikow commented Oct 13, 2017 • edited Loading

danday74 commented Jul 22, 2017 •

edited

Loading

paulmelnikow commented Oct 13, 2017 •

edited

Loading