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

Rethinking the dependencies badge #12

Open
theflow opened this Issue Feb 21, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@theflow
Copy link
Member

theflow commented Feb 21, 2018

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

This comment has been minimized.

Copy link

jrochkind commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Member

theflow commented Feb 21, 2018

@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

This comment has been minimized.

Copy link

bquorning commented Feb 22, 2018

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

This comment has been minimized.

Copy link
Member

theflow commented Mar 1, 2018

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

@thisismydesign

This comment has been minimized.

Copy link

thisismydesign commented May 7, 2018

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

This comment has been minimized.

Copy link

thisismydesign commented May 7, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment