Repository navigation
Check for version tags #30
Description
A good indicator of a well maintained open source project is the existence of Tags (or Releases). Some systems rely on existence of these (such as Bower), and while others use a separate system (Node) it can be incredibly useful for developers looking at a project to see tags for each available release.
IMO there are two ways of validating tags: generally, and language based.
Generally
Checking for the existence of any tags in the repo (e.g. asserting at the length of the Array in https://api.github.com/repos/basicallydan/forkability/tags is > 0) demonstrates at least some level of commitment from the developers to release stable versions.
Language Based
Looking at the choice of package manager, and discovering releases on that package manager, and tallying it up to the tags on github, for example http://registry.npmjs.org/forkability has 5 tags as of writing - 0.5.1, 0.6.0, 0.7.0, 0.8.0 and 0.8.1. We should expect https://api.github.com/repos/basicallydan/forkability/tags to have the same information - although the version tags typically start with 'v' which may need to be accounted for.
Activity
basicallydan commentedon Oct 12, 2014
Hey @keithamus thanks for the input!
Bower relies on the use of tags? Interesting.
I really like this idea, but I'm not entirely sure what the level of tag use is like. Given that it's required for projects which use Bower then I can certainly see the use of it there. But I must admit I'm slightly afraid of incurring the wrath of people who aren't too fond of tags. Do most good repos use tags in some way or another.
At the very least, checking for length > 0 I think might be wise.
As far as comparing npm/git for node projects, then, well... I think that could work quite well.
basicallydan commentedon Oct 23, 2014
Hey @keithamus, at a conference today I chatted with a man who described to me a use case for tags in open-source projects. To paraphrase:
So I'm convinced now! I'll make tags a requirement!
keithamus commentedon Oct 23, 2014
🎉
#30 Checking for no tags at all, first
basicallydan commentedon Oct 27, 2014
In 0.10.0, tags are being checked, but only the existence of them. I want to implement this for nodeJS tag parity before closing this issue :)
M-Zuber commentedon Nov 16, 2015
ping
basicallydan commentedon Nov 16, 2015
pong
@M-Zuber This is over a year old! Okay, so I guess the thing to do here is to check that for NodeJS projects, the tags are in NPM and in the repo. Agreed?
M-Zuber commentedon Nov 16, 2015
Sounds right, but we first have to check that the project is in npm.
We treat every js project as NodeJs project. But that does not say anything about it being on npm.
basicallydan commentedon Nov 16, 2015
Ah true. Probably straightforward though, just check if the URL is 404 or
not. Or maybe NPM has an api for this.
And then if the project is not on NPM, it doesn't get checked for this -
just git tags.
On 16 Nov 2015 18:51, "Mordechai Zuber" notifications@github.com wrote:
andrew commentedon Nov 25, 2015
@basicallydan I might be able to help out with the data for this issue, I've been working on an API for https://libraries.io which will let you get version info about a given npm module, you can also find all the npm modules that reference a particular github repo as the source code for that module.
Docs here: https://libraries.io/api, let me know if there's some other data you'd like that's not available and I'll see if I can add it
M-Zuber commentedon Nov 25, 2015
Thank you for taking the time to look at this.
What do we gain by calling your api as opposed to npm's directly?
Other than dependencies for the repo currently being linted 😉
M-Zuber commentedon Nov 25, 2015
Some other points:
we can't leave it open due to the second point:
Final point:
Is there a way we can get this set up in time for December? Preferably so that it will be
first-timer-onlyfriendly?basicallydan commentedon Nov 30, 2015
@andrew That is helpful, thanks - but we really only need the version tags at the mo which we can get from NPM directly. Thank you though, very good of you to point this out 😄
Given that Forkability is a browser- and Node-compatible tool it probably would be easier just to use the NPM registry.
I wonder if the NPM registry has a rate limit. @andrew do you know?
andrew commentedon Nov 30, 2015
Ah I didn't realise it was only for node projects, there's lots of useful tips for non-node projects here too.
As far as I know there's no rate limit on the npm api, or at least I haven't hit one yet
M-Zuber commentedon Nov 30, 2015
The general project is not only for node projects. Just the current focus for linting tags.
If the change discussed in #61 for the lint rules rewrite goes forward, then we can easily add checks for other package managers.
keithamus commentedon Nov 30, 2015
Using the libraries.io api might be a good idea because it abstracts away all of the package management stuff that you'd otherwise have to do. I guess the only problem with using it is the API key issue.
NPM's API is pretty easy to use and very forgiving, not sure about other package managers.
M-Zuber commentedon Nov 30, 2015
For sure once we get up to checking against multiple package managers it will be a blessing as its one api to code against. Until then we shall have to see
basicallydan commentedon Nov 30, 2015
@andrew @keithamus @M-Zuber I see now, very good point... I think that went over my head at first.
If we can keep it language agnostic then yes, my whole concern mentioned in #61 would be solved somewhat.
@andrew Does libraries completely normalise the output for versions regardless of platform?
M-Zuber commentedon Nov 30, 2015
I believe the changes being discussed in #61 are still relevant irregardless of the api being spoken to. Will try to clarify feedback on that, there
andrew commentedon Nov 30, 2015
I've not documented it but you don't actually have to pass an API key for the libraries api, the rate limit will just be based on your IP address.
@basicallydan yeah Libraries stores all libraries from every package manager in the same format, so the api is identical for everyone, some fields may have no value if the package manager doesn't support that feature.
For package managers that don't have a real repository like Go and Bower, Libraries fallback to GitHub tags for version numbers too, so you always end up with basically the same data, no package manager is a unique snowflake ❄️
basicallydan commentedon Dec 1, 2015
@andrew Frickin' Bower. Always ruining everything.
Okay, cool. That sounds great actually. I doubt any user of Forkability will be doing any heavy requesting over the limit, and when we get the library to work as a web service we can use an API key on the backend. Schweet. Thanks dude.
andrew commentedon Dec 1, 2015
👍