Upkeep

[olivroy]

The most "dramatic" change is the version and Date in DESCRIPTION

• usually, with devtools::submit_cran(), the date should add itself automatically.

I changed the version from 4.0 to 3.99.9000 to keep inline with the tidyverse version standards.

This has the following advantages:

• Makes it clear that it's dev
• Makes it easy to increment by 0.001, so 3.99.9001, 3.99.9002 as needed.
• The update is more likely to show up when 4.0 is actually released to CRAN.

Of course, if you don't agree, I can revert any of these changes.

Ran usethis::use_tidy_description() to order deps alphabetically.

Add logo as favicon to the pkgdown site

favicons are not built in CRAN, so their size doesn't really matter.

So it shows up when you open the site in the browser.

Taken from https://rzine.fr/publication/20180420_tmap_package/

THe compressed logo has an install size of 69 kb, if it's too much, it could be removed.

[mtennekes]

Thx! Is the version automatically updated after each commit? Say from 3.99.9000 to 3.99.9001?

[olivroy]

No, but note that it is not actually required. This could remain v3.99.9000 till v4 is released.

Once you fix something significant, it may just be useful for you to increment it. When users report their session info, it may be easier for you to know if they have the most recent fixes this way.

Most tidyverse packages do not change dev version, unless another package requires a certain fix.

Running usethis::use_version("dev") can increment version number as needed.

When you will be ready to release, you can use usethis::use_version("major") to increment to v4.

[mtennekes]

Thx, very useful info

[olivroy]

No problem. To facilitate release, tidyverse advises for creating an issue checklist.

usethis::use_release_issue("4.0")

On my side, I don't have too much to do for now. Thanks for letting me play in tmap!

I will study a bit more the internals of tmap to help consolidate documentation in strategic places (to avoid you having to use copy-paste all the time). See https://roxygen2.r-lib.org/articles/reuse.html for how to reduce duplication of docs. But I don't mind taking the lead on that ahead of the v4 release, as you will focus on finalizing the interface!

@mtennekes have you ever tried using vdiffr for visual comparison? If yes, what troubles did you run into? If no, would you be open that I try it?

[ ] I will try to find a way to make CI pass as soon as possible. (i.e. finalize testing) But I may not have time now, so feel free to resume the work on v4, using your priority list.

I want to edit data-raw to remove rgdal and make it easier to rebuild them (not a huge priority), but it seems fun for future reference and reproducibility.

I will continue investigating https://pkgdown.r-lib.org/articles/how-to-update-released-site.html to show v3, but it seems easier to create another repo? (it doesn't feel the effort is worth it on that side) that way, we'd have more freedom to edit some docs like README to point people to v4 and facilitate transition.