Answer

Transcript

Dan, can you just take a minute to discuss the best practices and exactly how people need to consider handling the config file as part of the release process?

Yes definitely, and we talked a little bit about this within the the best practices document that we have as far as how to manage this config file during a software upgrade process. So essentially the idea here is you just released a new version of your software. So the idea is users can upgrade from this older release to this new release. We generally actually recommend using the same configuration file. So the idea here is that regardless of what version a users running you know we're still going to reference the same config file. There are really two benefits to doing it this way so first of all what this prevents is double-counting of the same installation. So if a user upgrades from version one to version two, our philosophy is that that should really be viewed as the same installation. If you've got two different config files that are being created, one for v1 and one for v2, we would actually double count that end user as two separate installations because there are two separate config files that exist. So secondly this also allows us to track an installation across different product versions. So by managing this config file here across different releases, you'll be able to quantify how many users are upgrading again from v1 to v2 to v3 actually within the dashboard. You'll be able to more easily quantify that adoption rate.

Now similarly there are there are two different ways that you can accomplish this kind of managing of the config file during the upgrade process. So first you can ensure that the application data path isn't going to change during the upgrade process. So some examples of directories that are going to be universal or like the program data or app data directories within Windows. You could have a universal directory that the RUI client is always going to reference, that contains this config file regardless of what version the user has installed.

Secondly you could also have the application upgrade process actually handle moving the configuration file from one directory to another directory. Note that in this case if you're going to be moving that file we do require that that file is moved from one location to another and not copied. Because when you copy that file you can end up in the instance of similarly double counting users or having old data be associated with a new fresh install. Again, we talk a little bit more about that in detail within the best practices guide so if you haven't taken a look at that I would definitely recommend so.