Updated version of Chrome

[jdamhoff]

I am a newish filewave admin.

New version of Chrome browser is available. I have existing filesets for Chrome. 

What is the correct way to add the newest version of Chrome to a fileset for deployment?

[AnEngelsen]

@jdamhoff

TLDR: I recommend creating a Fileset revision.

*********

Full Explanation: The "default" revision is used by the majority of your devices. Other (new) revisions should be associated to a handful of beta devices, until you confirm that the new revision is "stable". Here's how to 'get started' with revisions:

1. Launch FileWave Admin (desktop app).
2. Click and drag the new version of Chrome.app on top of your existing Chrome fileset.
3. Choose Add revision to existing.
4. After the file upload completes, select the fileset. Then click the `Properties` button (top of window).
   1. Click the `Manage Revisions` button.
   2. Give the new revision a better name. (such as v105.0.5195.125)
   3. Click OK to confirm. Click OK again.
5. Create an association between the Chrome fileset and your "Beta" device(s).
   1. When you create the association you will be prompted to select a fileset revision. Choose your newly-created revision.
   2. Update the model.
6. When you're ready for everyone to start using the new revision:
   1. Select the Chrome fileset.
   2. Click the `Properties` button (top of window).
   3. Click the `Manage Revisions` button.
   4. Select the fully-tested revision.
   5. Click the `Set as default` button.
   6. Click OK to confirm. Click OK again.
   7. Update the model.

[Pierre-Nicolas]

Maybe a bit of History - Fileset had "version" since early days : each time you modify a fileset (add file, change requirements, edit kiosk), the version increases ; this allows you to know that something has changed, and to check that your changes have been propagated to devices (they report deployed version).

So when we introduced the concept of "multiple versions of an application in a fileset", we could not use version without changing a lot of existing material - and likely breaking backward compatibility. Hence we called this "revision".

Revisions make application upgrade smarter - without revisions, you have to:

1. schedule new version download
2. schedule old version removal
3. schedule new version activation

Which may cause the application to be unavailable for some time.

With revision, when you switch from revision 1 to revision 2, the agent will download revision 2 and update what is deployed -keep identical files, remove now-useless files and add new files - downtime is reduced.

One thing to mention is that there can be only one active revision at the same time - which means that if you have multiple associations for the same fileset with different revisions, the system will try to solve conflict (we have rules based on "distance" - can elaborate on this in another post) to figure out which revision will be deployed and made active now.

But this allows you to create complex scenarios - associate revision 1, associate revision 2 and schedule it to be active in 1 week ; the upgrade will happen.