colearendt / gitlink Goto Github PK

• Create branch labelled v[version]-rc, for example, v1.5.2-rc (the "rc" stands for "Release Candidate").
• Change the DESCRIPTION and NEWS on this branch to change the version number to the desired version for CRAN, e.g. from 1.5.1.9008 to 1.5.2.
• Commit and push to the RC branch.
• Clean your package directory to remove any extraneous files, including ones that are git-ignored. (Warning, this will delete any unsaved buffers in RStudio! Also, be sure to close RStudio before taking this step!) git clean -xdf .
  • NOTE: git clean -xdn . provides a "dry-run" list of what will be done / removed
• Build your package. I (jcheng) personally do it from the Mac command line like this:
• PATH=$PATH:/Applications/RStudio.app/Contents/MacOS/pandoc R CMD build [pkgdir]
• Do a sanity check by installing/testing the built package.
• Perform revdep check using https://github.com/r-lib/revdepcheck, if this is not the initial CRAN release.
• Run R CMD check --as-cran pkg_version.tar.gz both locally and on win-builder. You can also use https://r-hub.github.io/rhub/.
• I (jcheng) don't know how much it matters but I have this file as my ~/.R/Makevars:
• CFLAGS += -Wall -pipe -pedantic -std=gnu99 -g -O0
• CXXFLAGS += -Wall -pipe -Wno-unused -pedantic -g -O0
• CXX11FLAGS += -Wall -pipe -Wno-unused -pedantic -g -O0
• Read every bullet point in the CRAN Policies document if this is the first release of the package. I usually print it out and check off the items one by one.
• Submit to CRAN via their online form.
• If there are R CMD check warnings that are unavoidable, make sure to explain them in the comments.
• If rejected, make changes on the RC branch and bump the fourth (patch) version component, i.e. 1.5.2.1.
• When accepted, tag the RC branch with a v1.5.2.1 tag (or whatever version you finally ended up getting accepted), and push the tag to origin.
• Merge RC into master.
• On master, change the package version to 1.5.2.9000.

This seems like a nice "next pass":

https://github.com/tholman/github-corners/

Maybe something like corner_svg() or git_corner() that uses these examples... now whether to reference them from a hosted location somewhere or include in the package is something worth exploring... 🤔

When implementing the CSS version, if placing the image on the right, we end up with a horizontal scrollbar. This needs to be fixed.

Maybe embed the HTML itself: https://github.com/mdo/github-buttons

For instance, should we just focus on UI ribbons? Or should we focus on GitHub buttons and the like?

I.e.

• https://buttons.github.io/
• https://github.com/tholman/github-corners/
• http://code.danyork.com/2011/09/29/how-to-create-github-style-fork-me-ribbons-using-only-css/
• https://unindented.org/articles/github-ribbon-using-css-transforms/
• https://ghbtns.com/

Something along the lines of: https://jcheng.shinyapps.io/scorecard-app/

Example here, thanks to @andrie

<!-- ribbon from https://codepo8.github.io/css-fork-on-github-ribbon/ -->
​
<style>#forkongithub a{background:#FCECCC;color:#000;text-decoration:none;font-family:arial,sans-serif;text-align:center;font-weight:bold;padding:5px 40px;font-size:1rem;line-height:2rem;position:relative;transition:0.5s;}#forkongithub a:hover{background:#DFECF7;color:#000;}#forkongithub a::before,#forkongithub a::after{content:"";width:100%;display:block;position:absolute;top:1px;left:0;height:1px;background:#fff;}#forkongithub a::after{bottom:1px;top:auto;}@media screen and (min-width:1000px){#forkongithub{position:absolute;display:block;top:0;right:0;width:200px;overflow:hidden;height:200px;z-index:9999;}#forkongithub a{width:200px;position:absolute;top:45px;right:-45px;transform:rotate(45deg);-webkit-transform:rotate(45deg);-ms-transform:rotate(45deg);-moz-transform:rotate(45deg);-o-transform:rotate(45deg);box-shadow:4px 4px 10px rgba(0,0,0,0.8);}}</style><span id="forkongithub"><a href="https://github.com/sol-eng/sys-admin-cheatsheet">Fork me on GitHub</a></span>