Rethinking the dependencies badge

[theflow]

Let us know any feedback and ideas about our proposal for a new dependencies badge.

Try the new badge quickly by pasting your gemspec in our preview tool.

[jrochkind]

I think you have a good idea, and agree that the implied insistence on all dependencies being the latest at any given time is both unrealistic and counter-productive. There are often quite reasonable and good reasons not have 100% of your dependencies being the very latest release at some points. Yet on the other hand, the general state of dependency up-to-date-ness is a useful signal in evaluating software. I like that you are trying to find a better way to communicate/summarize this signal, hard to say how will it will succeed without seeing it in practice.

I think it's possible the score idea could be good after all --- I mean, do we really know what "recent" or "behind a little bit" means without clicking through either? We might think we do, just we might or might not for a raw score, but there is editorial judgement involved in the algorithm in both cases. But I'm in favor of trying out anything new! Perhaps both a score and a categorical summary would be useful together, or perhaps something else entirely. I think the conscientious evaluator will probably want to click through in any event to see the details (how many dependencies are a major version behind, and what are they? What are the dates the new major version they don't have was released; yesterday, or two years ago?), so making the click-through page as "legible" as possible for the use case of someone evaluating third-party software (a somewhat different use case than the maintainer(s) themselves) is probably worth spending time on too.

[theflow]

@jrochkind thanks for the input!

I'm also curious about pursuing the score, but I was thinking it would lead towards somehow scoring the health of the library itself: is it well maintained, how many releases, open bugs, along those lines.

[bquorning]

I looked at https://github.com/jaredbeck/libyear-bundler recently – it will tell you “how out-of-date your Gemfile is, in a single number”. A number like that (perhaps divided with the total number of gems in the application being checked) might be useful in your dependency badge.

Just ensure it works with private gem servers too, which I think libyear-bundler doesn’t. 😉

[theflow]

Thanks @bquorning, I didn't know about libyear, that's a very interesting approach.

[thisismydesign]

I like the idea.

I find the number of dependencies to be often as important as their state, especially in case of small projects. Having little to no runtime dependencies is a huge plus. I saw that you have a "count of outdated dependencies". That's a great start. I was wondering how the color coding works there? I assume it's the same (as recent, stale, etc.) but in that case I find it a bit misleading: e.g. you could have a green badge saying 10/10 outdated. For me what would add the most value is a badge that states the number of dependencies and their overall state, so somewhat a mixture of the two (i.e. I'm not interested in how many dependencies are slightly outdated). Something like: dependencies | 3, stale would be awesome. Or a simple badge with the number of runtime dependencies would also do, which can be used together with the summary one.

[thisismydesign]

Additionally it would be great to have badges per branch. I.e. development and release branches might differ a lot.