The "Version Release Management Process" described here is the process that we sometimes use to control what application version is released to who and when.
The typical environment where this would be implemented would be in a client-server or peer-to-peer network where the database is shared and each users' PC has its own copy of the application file. The application file could be left on the server for all clients to use, but distributing it locally offers some speed improvement through reduced network traffic.
This process is ideal for an environment where frequent updates are made to the application file and we don't want to manually distribute the file to each users PC and we don't want to make the user run a batch file to force the download of a new file each time the system is started.
How does the process work? The shared network database contains the current application version number and the location of the current application file stored in a system table.
The local application file also has its own version number identifying it. A comparison is done between the local app and the current app when the system is started. If the application is outdated and the user accepts the opportunity to upgrade, then the copying applet is started and the user's app is shut down.
The copying applet backs up the users application file and copies the source current application version to the location of the users application file and starts it.
This process can offer a lot of control over who gets what version and when. When we advise the user about the availability of the new app, we might show a list of changed features in it. We could also send a different application file depending on the security group the user belongs to.
(Click the picture for a larger view.)