Managing Upgrades of R
There are various ways to handle upgrades to new versions of R ranging from allowing each user to control exactly when they upgrade all the way to forcing everyone to upgrade all at once.
By combining the various options described above you can create a highly customized upgrade policy that reflects both your internal policies and the preferences of your users.
User controlled migration
The most conservative approach is to start with a default version of R and preserve that default for the lifetime of the server. In this configuration, you can continue to install new versions of R as they are released. However, users won’t ever run those new versions unless they make an explicit gesture to do so. See the User Configurable Default Version and Switching between versions sections for details on how users can explicitly switch versions.
Partial migration
If your posture towards new R versions is that you’d like users to migrate to the new version(s) as quickly as is convenient, you can be more aggressive in how you introduce them. In this scenario, you might use the Default version per user or group feature to migrate a portion of new users immediately but preserve older versions for those who request it.
Note that in this scenario, R projects will still preserve their previous R version so long as users have enabled the option described in Preserving versions for projects.
Full migration
The most aggressive approach is to force all users to upgrade to the new R version immediately (this is essentially what happens in the open-source version of RStudio Server). To implement this, you’d set a Single default version of R as well as disabling the use of multiple versions as described in Disabling use of multiple versions.
Note that via User and Group Profiles you could also have a subset of R users that are always fully migrated to new versions while preserving user controlled migration or partial migration for others.