-
Notifications
You must be signed in to change notification settings - Fork 27
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
Convert dependency status images to crate based. #39
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change for fontique is definitely correct, but the top-level change is less clear.
Ultimately, I think this is fine, but it is a decision to be made when we have a finalised badge set
@@ -6,7 +6,7 @@ | |||
|
|||
[![Latest published parley version.](https://img.shields.io/crates/v/parley.svg)](https://crates.io/crates/parley) | |||
[![Documentation build status.](https://img.shields.io/docsrs/parley.svg)](https://docs.rs/parley) | |||
[![Dependency staleness status.](https://deps.rs/repo/github/linebender/parley/status.svg)](https://deps.rs/repo/github/linebender/parley) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So yeah, this is one of the things I grappled with for android_trace.
My conclusion was that in the repository level readme, we should have a repository level badge.
But for each individual crate, the badge should be for the released crate.
I have not yet thought that hard about crates with a top level crate - i.e. where there is no distinct repository level readme. The options there are:
- make there be a top level readme, i.e. move
parley
intocrates/
(orparley/
) - Don't have the repository level badge
- Have both
I don't think it's viable to have both, and it's definitely not viable to have the badge in the published crate be for the repository.
But I do also think that the repository level badge is useful, for a more updated status
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think not having a top level crate might be the way to go for repos that have more than one publishable crate. The reasoning for this gets stronger with every additional crate in the repo. The dependency badge is just one thing, but it would be nice to have all sorts of info and discussion about the repo and the crates in it - but none of that really fits the top level crate's readme on crates.io etc.
Let's discuss this further in the upcoming badges etc discussion. For now I'll merge this as-is and we'll change it later to whatever the big decision will be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(meant to approve)
The
fontique
dependency status image was wrong because it was pointing to a non-existent repo. While theparley
one was showing an out-of-date dependency that was actuallyfontique
's dependency.This PR converts these images to be crate based instead, like this: