SkaDate Dating Software Update: Word from Developer

The release of a new software version (like SkaDate 9) means that we modified the original code of existing files and also added new ones.  This is necessary for the implementation of new features and functions.

If a client never introduced custom changes to files modified in the new SkaDate version, the update of these files will be as easy as it gets – said files can be simply replaced. It is, however, a different story, if some changes have been made after all.

If that happened, custom code changes should be merged with alterations done by our programmers in the new SkaDate build. This is absolutely vital for not losing modifications introduced before the release of the new version.

(Just to be clear – file merging is the manual transformation of previously made modifications, with the goal of making them conflict-free compatible with modified files and features of the new build).

That’s how it works in any real open source PHP software, and that is why it is impossible to create some sort of automatic update system for similar PHP applications. Simply put – it is virtually impossible to automatically update everyone’s software, retaining all of the custom modifications introduced by hundreds of customers.

For instance, take Word Press – the popular blogging software. Indeed, it does has an automatic update feature. However, said update overrides all custom code changes made by users, so any modifications will be lost if it is used.

We knew about this issue even while working on our first ever update script, and we tried to find a solution. It seems that the only way to make the process easier for customers is to introduce a semi-automatic update script.

This means that our script can compare files of a customer’s SkaDate version, with files of the same default version (without custom modification), and also with files in the new SkaDate build. Let’s see how it works, using the file index.php as an example:

• If the file was not custom-modified by the client, but was revised by us in the new build, the script will automatically overwrite it;

• If the file did not exist at all in client’s current and our default versions, but appeared in the new build, the script will automatically add it to the current version;

• If the file was custom-modified by the client, while we have also introduced some changes to it in the new build, the file will end up on the Merge List. This tells the client that the file must be merged with both – custom changes and changes introduced by us in the new build;

• If the file exists in client’s current and our default versions, but is not present in the new build, it will end up on the list of files to be removed. The script does not do it automatically to avoid the risk of deleting files by mistake, thus losing some of custom changes.

Hopefully, this shows that we indeed tried our best to simplify and semi-automate the update process as much as possible, while retaining all of the custom code modifications. Any other way of automatic update will result in the loss of all custom modifications.

Note, that the person performing an update should have at least a basic knowledge of PHP programming, since updating any PHP software is the same as working on a custom modification – PHP code will be accessed directly.

We have a number of clients who have necessary PHP skills and perform all of the updates on their own. At the same time we also allow our customers to work on updates without our input, by hiring third-party specialists. However, we also have a paid service in house just in case clients are not qualified enough to work with PHP, or simply prefer to not be bothered with updates at all. In the end it’s the customer’s choice.