-
Notifications
You must be signed in to change notification settings - Fork 335
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
Consider installation and badges for development version of site #1299
Comments
To expand on this a bit (it came from a slack convo), the main user-facing badge, if we have one on pkgdown landing page, should reflect the installation and usage experience that user is likely to have based on our testing. Having this badge reflect the worst result across the most recent run over a large build matrix seems too changeable / disconnected. If there were more substantive differences like this, I think it might help maintainers decide whether to have a release vs. dev site and, if so, this provides motivation for it. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I think there we probably want three categories of
So maybe Not sure whether we want "hide" or something else, since presumably we want to remove all together, not just hide with css |
The sort of place where you'd see these class names are: [![CRAN Status](https://www.r-pkg.org/badges/version/pkgdown)](https://cran.r-project.org/package=pkgdown){.hide-release} This would primarily be accessible from .Rmd, not .Rd, since we don't have any good general ways of adding classes in .Rd. |
Or maybe |
For popular tidyverse packages, displaying the GitHub installation instructions and the development badges causes more problems than it solves. Maybe we could display them only for the development version of the site when dev mode is set to
auto
?(At the same time, it would be nice to have a separate sidebar entry that somehow captured best development practices like using unit tests, code coverage, CI, ...)
The text was updated successfully, but these errors were encountered: