AboutSupport

RVM version control

Suggest Edits

A key strength of the OpenFin ecosystem is that you can use automatic updating to ensure that your application is always running on the latest versions of the RVM.
However, some organizations want to control what version of RVM is running in their enterprise environment, as well as the timing of when versions are upgraded.
Historically, they have implemented solutions such as self-hosting OpenFin assets or turning off auto-updating.
This can lead to situations where the organization is using outdated versions or missing out on security updates.

Starting in RVM v11, desktop owners can define controls over the OpenFin RVM version, using a desktop owner setting to control what versions are automatically updated on the system.

You can control what versions of the RVM are allowed to be installed by the auto-update mechanism.
If you manually update a version, you bypass this control. However, the manually-installed version might never be auto-updated, depending on the version control setting.

Why control the RVM version?

Here are a few use cases for controlling the version of RVM in an organization:

  • You want to temporarily pause updating to the latest RVM until you are ready to do so.

  • You want to ensure all end users are on a specific version of the RVM.

  • You want to vet any major change to the RVM but ensure minor updates and patches are installed as soon as possible.

How do you control the RVM version?

You can specify allowed RVM versions using the desktopSettings.deployment.rvmControls.versionPattern property in desktop owner settings.

Version patterns

Version patterns consist of four numbers with dot separators.
A version pattern can contain the * character as a wild card for a level, or it can be a fully-specified version string.
For example:

  • 15.1.*.* allows any version that starts with 15.1 but not versions starting with 15.2. or 16.. This is a typical usage.

  • 15.1.2.3 is a fully-specified version; the RVM will not update past this exact version.

  • 15.1.*.3 is an invalid pattern; numbers cannot follow wildcards in the pattern.

  • 10.*.*.* is an invalid value; this property is supported for version 11 and later.

Example RVM version control

The following example shows how the property appears within a DOS file:

{
 "desktopSettings": { 
…
   "deployment": {
…
    "rvmControls": {
       "versionPattern": "15.1.2.*"
    }
   }
 }
}

How does it work?

When this setting is configured, the RVM's automatic update mechanism updates only to the highest version allowed by the version pattern.

  • The RVM must be able to access one of the following, in order to check for available versions:

  • The RVM writes to the RVM log in the following cases:

    • This setting blocks an update of the RVM version.

    • The value of the setting for is invalid due to specifying a version that does not support the setting.

    • The value of the setting is logged whenever an RVM or an application launches.

Related settings

assetsUrl

The assetsUrl setting specifies a location from which to download OpenFin assets, including the RVM and Runtime.
The rvmControls setting is intended to avoid the need to use a local server for OpenFin assets purely to control OpenFin versions.
You might have unrelated use cases for this setting.

disableAutoUpdates

By default, when the RVM starts, it attempts to automatically update to the latest stable version.
You can disable the auto-update mechanism with either the [disableAutoUpdates registry key](doc:group-policy-and-registry-settings1) or the --disable-auto-updates command-line flag.

If you do not disable auto-updates and you configure rvmControls.versionPattern, then only versions matching the version pattern are auto-installed.
If you do disable auto-updates, then the RVM does not attempt to update, so rvmControls.versionPattern is not read.

Application minimumRVMVersion

An application can set a minimumRVMVersion in its application manifest.
It is possible to have a conflict between the application's minimum RVM version and the desktop owner's specified RVM versions; for example, the app's minimum is 15.*.*.* and the DOS RVM version pattern is 14.*.*.*.
In such a case, the currently available RVM version is lower than the application's minimum, so the application fails to start and an error dialog is shown.
If there is no RVM running when such an error occurs, the RVM aborts and does not continue running.

trackBetaAutoUpdates

The trackBetaAutoUpdates setting causes the RVM to automatically update to the latest beta release.
If both trackBetaAutoUpdates and rvmControls.versionPattern are configured, then beta releases are included when determining whether a release can be installed.
However, depending on the version pattern, this combination might limit the usefulness of trackBetaAutoUpdates.
The two settings are not intended to be used together.
The trackBetaAutoUpdates setting is intended for developers, whereas the rvmControls setting is intended for end-user deployment.

whitelist.allowedRVMVersions

The whitelist.allowedRVMVersions setting can contain an explicit list of RVM versions. This setting is ignored if rvmControl.versionPattern is defined.

📘

Note

The whitelist object is planned to be deprecated and replaced by allowlist in a future RVM release.

Updated 4 months ago