|
Concepts & Definitions
For the subsequent statement it is necessary to define some important terms which have specific meaning in the context of PatchFactory v3.
Product
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 on it: the global unique identifier (GUID), the name of the product, the manufacturer of this product and others.
Product Parameters
- Each product has two main parameters: Product Name and Product GUID.
- Product Name must form a valid name of file thus using of such symbols as < > : " / \ | * ? is not allowed.
- Product GUID is generated automatically when new product is created and is not changed.
- Other parameters are optional and reserved for future use.
Version
- 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 below.
To have an opportunity to present interrelation of versions among themselves we shall enter one more important attribute of the version - the parent version or the 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 all set of versions of a product as a versions tree. If versions have no previous - they are so-called root versions or primary version. Any version can be root. Thus, the number of primary versions is not limited. From here follows, that versions tree does not contain a single root, so a product can assumed as a root of the versions tree.
Component
All files included in the version are grouped into components.
Each component of the version can 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 a tree of 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 a component corresponds to the term accepted in the majority of modern install-generators.
The key parameters of a component are the component identifier, unique among all components of the given version, name of the component and the flag of optional installation of the 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 one file of a 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 life time".
Version Difference
Let's name a set of the information which defines the difference of one version from another, as a Version Difference. Besides difference in files, it can describe rules of update building and applying and other necessary data.
Update module, Patch
The program module which carries out the updating of version, already installed on the end-user's side, up to some other version.
Update is made on the basis of difference(s) between versions.
Hereinafter we assume (when talking about a "patch" as program object) that version which this patch belongs to is new comparing to other versions of the product and this new version contains at least difference.
Using PatchFactory you can make patches of 2 types:
v2v-patch
This type of patches is capable to execute updating of only one version up to one another. Let's assume, that you have three versions of your product: 1.0, 1.1 and 1.2. To update versions 1.0 and 1.1 up to version 1.2 with the use v2v-patches you should prepare two separate update modules.
Cumulative patch
This type of patches allows to update one of the several specified versions up to one other version by means of one patch module. In the example of previous paragraph, cumulative patch applying allows to generate only one update module which can be used to update both versions 1.0 and 1.1 up to version 1.2.
Patch Publishing
The patch prepared by the 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 a simple case Patch Publishing can look as placing of a patch-file on a company's web-server or a ftp-server.
Disadvantages of such approach are obvious: both publishing and its delivering of a patch should be carried out "manually".
Update Server
A server on which update modules are published. Access methods to server and protocols used at the current stage are insignificant.
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.
»
| 
