R 4.0 release

[xhdong-umd]

In testing with R 4.0, I found devtools have a bug for windows:

• rlang have 0.4.5 binary, 0.4.6 source. If you chose to only install binary version, then chose upgrade all dependency packages from CRAN, it will always try to install rlang again even if you have it installed already, and that will cause failure because devtools itself loaded rlang.

This can be fixed with either install rlang from source, or use remotes::install_github, because remotes doesn't load rlang.

With R 4.0 and a fresh library install, I counted that ctmm need 20 dependency packages, ctmmweb need 108 (!) dependency packages.

[xhdong-umd]

Previously I built a drat repo so user can install packages with install.packages instead of devtools, because I met package installation problems with devtools many times and it's often hard to solve for users.

However to maintain that drat repo is kind of cumbersome, I need to do many manual steps. I'm thinking no longer use it as main method, but just ask user to use remotes::install_github, which has much less dependencies than devtools, and almost always works in my previous experience.

I think I can also try to submit to CRAN in the near future, which will serve as the "release" repo.

[xhdong-umd]

@jmcalabrese , I'm debating about the link to windows installer. I need to update the installer to install R 4.0, then I can

1. still use the existing link, update it, so the installer link never change. However it's attached to version number 0.2.6b, which can be confusing when version number increased.
2. I can also attach it to a most recent version number, like 0.2.10.

Previously the paper review was asking a permanent link so I think option 1 was better as the link can stay the same. But the explanation itself made me think maybe we don't need to stick to that "permanent" as the benefit of a link stay same may be less than the confusion of a lower version number in the link.

If you agree with option 2, we need to change the response to that question too.

[jmcalabrese]

@xhdong-umd Recommending remotes::install_github sounds like the cleanest solution. If you update the recommendations on GitHub, I will put that in the response letter and paper.

Also, I'm fine with option 2 regarding the Windows installer. One question though: Does the version number explicitly need to be included the in the URL? E.g., could the underlying version number remain fixed at, say, 0.2.10, while the URL that links to that fixed version number just says "current" or similar?

[xhdong-umd]

I have updated the readme and documentation about installation in github with remotes::install_github.

As for the installer link, it does have to be attached to a certain version as this is the only way to host binary file in github. I'll also send some updated response for this through email.

[jmcalabrese]

I understand that the link has to point to a fixed software version, but my question was does the version number have to explicitly appear in the URL?

[xhdong-umd]

Yes it has to have the version number. Someone mentioned that the link actually point to a file in Amazon S3, but I think that kind of url will look more strange.

[xhdong-umd]

I just sent the revised response about installer in email. It's a little bit confusing, but I think update it with new versions has less surprise for users compare to a "permanent" link with an old version number but update silently.

[xhdong-umd]

Next I will implement some changes in manually marked outliers to sync with changes in ctmm end, update documentation and website, attach the new installer with new version etc.

[xhdong-umd]

I have implemented changes on outlier, updated installer with R 4.0, bumped version to 0.2.10 and updated installer link in readme and installation page.

Next I'll update the hosted version.

[xhdong-umd]

Hosted app updated. I found the diganostic info is still hit or miss sometimes. The intention for that is to collect some server info in case user met problem in hosted app. But this rely on redirecting error msg and can be quite tricky to debug and make it right when something wrong happened. I haven't see any user case of this feature get used.

I'm planning to disable this feature, but make the app/package version report easier, and just ask user to always update to latest version before asking any questions. Then we can collect more information as needed.

[xhdong-umd]

After extensive tests, I think I finally fixed the problem with diagnostic info. I also updated the hosted version.

[xhdong-umd]

I turned off the drat repo (which was used to install package through install.package by customized repo, this is not used now as every update need some manual work, and remotes don't have much problem), updated the package website to latest.