For the subsequent statement it is necessary to define some important terms which have specific meaning in the context of PatchFactory v3.
Let's assume a Product as a certain software program or simply any set of binary files which undergo some changes eventually. For example, we develop software product which is named PatchFactory. A set of attributes associated with this product represents essential information: global unique identifier (GUID), name of the product, manufacturer of this product and others.
Each product has two main parameters: Product Name and Product GUID.
Product Name must form a valid file name, thus using of such symbols as < > : " / \ | * ? is not allowed.
Product GUID is generated automatically when new product is created and it is not changed later on.
Other parameters are optional and reserved for future use.
The version is the change of the product supposed to be published and fixed at some stage.
The obligatory attribute of the version is the identifier of the version which should be unique among all version identifiers for this product.
To define the number of the version the line identifier is used, for example: "1.2b" or " 3.7 (build 465) ". Restrictions on version number format and symbols are listed in the "Version Parameters" table.
To have an opportunity to present interrelation of versions among each other, let's introduce one more important version attribute - Parent Version or previous version which will designate the version the current version originated from. For each version there can be only one previous version (single inheritance). In other words, each version can have only one parent or not have it at all. At the same time, any version can be parental for any number of versions. Such approach allows us to present the whole set of versions of a software product as a Versions Tree. If versions have no previous one - they are so-called Root Versions or primary version. Any version can be a Root Version. Thus, the number of primary versions is not limited. From the above it follows that the Versions Tree does not contain a single root, so a product can be assumed as a root of the Versions Tree.
View available Version parameters...
All files included in a version are grouped into components.
Each version component may contain a set of folders and/or files. Components applying allows to easily allocate independent groups of folders/files which can have separate location in the tree of the file system on the end-user's machine, and probably can have an optional installation property, i.e. can be installed or not.
In general, the concept of components corresponds to the term accepted in the majority of modern install-generators.
The key parameters of a component are: component identifier, unique among all components of the given version; name of this component and flag of optional installation of this component.
To detect whether a component is installed on the end-user's machine or not, we use the key file method. The idea of this method is that one file of each component is marked as the Key. Its presence in the system determines the fact that a component is installed or not.
Thus we have 3 main requirements for a component and a Key file:
|▪||each component should have at least one file;|
|▪||each component should have one and only one Key file;|
|▪||Key file should exist during all "component's lifetime".|
View available Component parameters...
Let's name a set of the information which defines the difference between two versions, as a Version Difference. Besides difference in files, it can describe rules of update building and applying and other necessary data.
The program module which carries out the updating of the version of a software product, already installed on the end-user's side, up to some other version.
Update is performed on the basis of difference(s) between versions.
Hereinafter let's assume (when talking about a "patch" as a program object) that version which this patch belongs to, is new comparing to other versions of a software product and this new version contains at least one difference.
Using this type of patches provides updating of only one version up to one another. Let's assume, that you have three versions of your software product: 1.0, 1.1 and 1.2. To update versions 1.0 and 1.1 up to version 1.2 using v2v-patches you should prepare two separate update modules.
This type of patches provides updating of a one of several specified versions up to one other version by means of only one patch module. For the example of the previous paragraph, a cumulative patch applying provides building of only one update module which can be used to update both versions 1.0 and 1.1 up to version 1.2.
View available Patch parameters...
The patch prepared by software developer should be delivered to end-users. It is obvious, that taking into account its small size (comparing to the full new version distribution package), the most convenient way is to provide an access to these update modules via Internet. In an elemental case Patch Publishing can be implemented via placing of a patch-file on your company's web-server.
Disadvantages of such approach are obvious: both publishing and its delivering of a patch should be carried out "manually".
Let's name the Update Server as a server on which update modules are published.
Access methods to server and protocols used are insignificant at the current stage.
A schematical sketch of the overall update cycle with different types of patches is shown in figure 1.
Figure 1. An example of an update cycle with different types of patches.