Application Updates

An application may declare versions of packages which can be updated to the current package.

Update Strategies

Two update strategies are supported:

• patch - a version change without major changes in the application settings and without any changes in the deployment logic. In particular, all allocated resources are left as is, and no changes in the application mapping scheme are allowed.

  Moderate changes in the application settings are allowed, however several classes of changes which may lead to ambiguity are prohibited. See details in the “Service Settings” and “Service Requirements” sections.

  Such restrictions allow unattended update of all application instances, thus making patches a preferable way to apply crucial changes, such as security fixes. If a patch fixes a security problem or a problem that affects all software users, it SHOULD declare the recommended element. Otherwise, it is assumed that the patch fixes some specific problem, or implements additional functionality and is intended to be installed only by those users who are experiencing the problem.

• upgrade - a version change which allows complex changes in the application settings and the deployment logic. This operation may require user attendance.

<application>
    ...
    <patch match="version =eq= 6.10"/>
    <upgrade match="version =eq= 6.0"/>
    ...
<application>

A Package may specify which versions it can update with the help of a match attribute. This attribute contains an RQL expression that will be evaluated against the metadata of the installed packages with the same id (or a name/packager pair for older packages) and lower version/release numbers.

If the specified RQL expression will be evaluated to true on some examined application metadata - the package is considered to be an update for the examined application.

Note

The limit, sort, implementing, composing, and isnull RQL functions cannot be used in expressions to be evaluated against package metadata.

The upgrade script is executed after replacing the old set of the application files with the files from the new version of the application.

Note

A Controller MUST refuse to upgrade an application if there are resources created by a service which is removed during the update.

If the update specification is absent, a Controller assumes that updates are not supported by the package at all.

For exact version comparison a Controller MUST be able to compare package versions as specified in the Package Version section of the specification with help of the =lt=, =gt=, =ge=, =gt=, =eq= and =ne= RQL operators

Specification of exact updatable versions

<application>
    ...
   <patch match="(version =eq= 2.0,release =eq= 1)
              or (version =eq= 2.0,release =eq= 2)" recommended="true" />
   <upgrade match="version =eq= 1.0,release =eq= 1" />
    ...
<application>

Such specification means that the package can patch an installed version 2.0.1 or 2.0.2 and upgrade version 1.0.1.

Specification of updatable version ranges

<application>
    ...
   <patch match="version =gt= 2.0" recommended="true" />
   <upgrade match="version =gt= 1.0" />
    ...
<application>

Such specification means the following:

• If the installed version is greater than 2.0, a patch is possible. The patch contains crucial fixes, affecting all application users.
• If the installed version is greater than 1.0 and less or equal to 2.0, an upgrade is possible.

Update Process

• Every resource allocated for an application instance as a result of satisfying the relations must be preserved during application upgrade unless a new version of the application has dropped the relation. The exact semantics of preservation is specified in the description of the resource type.
• No changes in resource relations are allowed during patches. Therefore, the APS Controller preserves all resources related to the previous version of the resource and does not analyze the relations of a new version.

← Package contents listing (APP-LIST.xml)

Application Services →