cran release

[lorenzwalthert]

Prepare for release:

• [x] devtools::check_win_devel()
• [x] Polish NEWS
• [x] If new failures, update email.yml then revdepcheck::revdep_email_maintainers()

Perform release:

• [x] Create RC branch (for bigger releases)
• [x] Bump version (in DESCRIPTION and NEWS)
• [x] devtools::submit_cran()
• [x] pkgdown::build_site()
• [ ] Approve email

Wait for CRAN...

• [ ] Tag release
• [ ] Merge RC back to master branch
• [ ] Bump dev version
• [ ] update CRAN speed change monitor PR.

[lorenzwalthert]

@assignUser I suggest to pause the CRAN release process until you implemented more features.

[assignUser]

@lorenzwalthert I think once #59 and #60 are merged we can continue with the cran release?

[lorenzwalthert]

The problem is that I was using attach() and the CRAN maintainers did not like it, although I followed best practices (see cran-comments.md). We might have to export expr_eval() to get through.

[assignUser]

@lorenzwalthert what about withr::with_namespace?

[lorenzwalthert]

Good idea! We'll have to try that I think...

[assignUser]

I think we could proceed with CRAN submission now or do you have some other things you want to implement?

[lorenzwalthert]

Well I have a list I once mentioned... Will try to put the items out as issues. Things on top of my mind:

• API review, i.e.
  • benchmark_run_ref() should probably be called benchmark_run() only.
  • Not sure we should continue to use the notion ref(s). Because it might be misleading, since the refs are mostly branches (i.e. heads), not arbitrary commits on a branch. Also, you can create a branch from an arbitrary commit and benchmark it, so for people who are not git geeks, using branch might make more sense than ref. This affects exported function names and arguments and documentation.
• An explanation of which level does what (run_script(), within script, within benchmark_run_ref() and how these relate to activate(). I have some drawing I could digitize.
• More examples, even if it's only a GitHub search link like this who uses {touchstone}. The template is already a good start.
• make package known and ask for testers, e.g. on Twitter. Fix final things before CRAN submission.

What do you think about these things?

[assignUser]

• API - Agree on both poInts
• Extra documentation is always good but if I think back to my first contact with {touchstone} the template/readme made the overall workflow pretty clear, so I don't think it would be strictly necessary-
• I like the idea of the github search link so users can peek at others usage of the package!
• I will sadly not be of much help in spreading the word via twitter or other social media. We could maybe do something for https://rweekly.org/, r-bloggers or something similar? If we want to put in a bit more effort maybe submit to https://joss.theoj.org/ ?

[lorenzwalthert]

• API: Ok. If you have time, you can review it and propose the changes. Not sure we want to hard-deprecate the old functions already now 🤔. Probably we could since no one else on GitHub seems to use our package yet.
• Let's leave the extra docs then, I'll add the link somewhere to the docs.
• Twitter: I can do this after we resolved the API thing above, then we could do R weekly after CRAN submission. I leave it to you if you want to do JOSS (and do the work), I don't have time for that 😀.
• We can also do a blog post on my personal blog, it's linked with R bloggers. We could already prepare that before the CRAN release so we can publish it right after. Probably a summary of README and Get started vignette plus some of your / my personal use case...

[assignUser]

Ok sounds good. I think the time to hard-deprecate stuff is now, before anyone else uses the package :D I will think about/write up a draft for JOSS, I think being on cran would be good for that though, even if we then can include the citation only in the next cran version.

[sbfnk]

Was this abandoned due to difficulty with complying with CRAN? Would be great to have a release (and/or even a JOSS article).

[assignUser]

I think it was more a case of other responsibilities taking over. I don't think the package has anything that would make a CRAN release especially difficult (e.g. no compiled code), so it's more a question of time/contributions.

[lorenzwalthert]

Yes. If you want to submit to CRAN, and / or become maintainer, I am happy to transfer the GitHub repo over. I don’t have time to work on this package anymore. Sorry.