Why Niakwa Provides Maintenance Releases This Way
A common question is "why does Niakwa provide maintenance releases as a copy of the entire setup routine, rather than just providing the changed files?" Here is why:
The setup routine sometimes (especially in the case of NPLSecure installations) installs and registers certain components. These components are not likely to be in the NPL directory, making it difficult to just copy them over. Also, some of these files may involve the NPLSecure Server service. If these files are changed, then to replace them by hand would require you to stop (and remove?) the service, then replace the files, then make sure the service is started (and installed?) and set to Auto, and possibly reboot somewhere in there. All of which would be easier by removing the RunTime and reinstalling it.
One of the advantages of using the entire installation when testing a maintenance release is to test the entire installation process. That way, when installing at a new customer, you can simply take the new version intact. You would not have to install the CD version, then copy extra files afterward. This will make new installations much easier, especially since the copying would have to be done at each workstation.
Another advantage to testing it this way is that when a maintenance release has been in the field for a while, Niakwa can be confident it has been field tested, and can then simply put it into the shipping release. This will allow us to update the shipping release more often, which will improve the quality of the product we deliver, and make it less likely you will have to use maintenance releases at all.
Why recall and install security? Sometimes some of the changed files are related to security handling. The only way to benefit from these changes is to recall security, replace the files (preferably with setup.exe), and reinstall security.
Although it may seem burdensome, our recommended method is the only way of assuring the Maintenance Release is applied completely and properly.