I have defined restrictions on upgrade in my package but the upgrade from restricted version still seems to be possible according to POA CCP UI:
<version>5.7</version> ... <upgrade match="/application/version > '5.5'"/>
Here, you can see that applciation version
5.5 is provisioned but upgrade to
5.7 is available despite
<upgrade match="/application/version > '5.5'"/>.
This is the intended behavior, because there most likely exists a bridge package between the incompatible versions.
In this case, POA detects it and makes the upgrade available. If the upgrade is requested, it is performed step-by-step from the first to the last version.
There may be more than 1 bridge package.
You have 3 packages with the same ID:
5.7, upgrade match:
version > '5.5'.
With these directives, you intend to restrict straight upgrade from
5.7 (for whatever reason).
However, after uploading all 3 packages and provisioning version
5.5, you notice that upgrade to
5.7 is available from CCP.
This is because version
5.6 is also available and POA detected that
5.7 upgrade scenario is possible. When you request an upgrade, it will schedule upgrade from
5.6 first and then from
5.7 effectively meeting the requirements specified in the packages.
Note: this will happen even if you disable version
5.6 (bridge) from PCP (make it unavailable to customers). This can only be prevented by removing version
5.6 from POA altogether.
aps_packages_upgrade_relations table will look like this:
plesk=> select * from aps_packages_upgrade_relations; app_id | src_ver | tgt_ver | rel_type --------+----------+---------+---------- 100 | 5.5-1 | 5.6-1 | u 100 | 5.5-1 | 5.7-1 | s 100 | 5.6-1 | 5.7-1 | u
5.6 will cause all 3 records (and upgrade possibility) to disappear (as there are no upgrade relations for the package if bridge package is unavailable).