Patches and customizations

Sometimes, the vendor of the standard parent product applies patches instead of Feature Packs as a method to provide incremental updates to the market. As opposed to Feature Packs, patches are not cumulative. The installation of a patch in an update VRC requires that you also install all preceding update VRCs in the same update VRC. This issue has consequences for the VRC setup at the distributor.

In most cases, you use a single environment to develop and to maintain multiple customizations. You build every customization on a specific patch. In addition, you must periodically upgrade existing customizations to a newer patch. Therefore, you must have multiple Feature Packs of the standard parent product that is installed in separate VRCs. The best way to achieve this is through this method:

Install patch 1 of the standard parent product in update VRC P10U_a1_stnd. When patch 2 is available, install the patch in a new, separate update VRC P10U_a2_stnd, which is derived from P10U_a1_stnd. Patch 2 has patch 1 as a prerequisite. You cannot install patch 2 in the new update VRC P10U_a2_stnd because patch 1 is not installed in this new update VRC. Therefore, run the session and copy the registry of update VRC P10_a1_stnd into P10_a2_stnd. After you perform this step, you can install patch 2 directly in the P10U_a2_stnd update VRC. You can then repeat this same process for subsequent patches. The P10U_a<n>_stnd VRCs must only contain net patches. No additional solutions must be installed in these VRCs that do not belong to the relevant patch.

At this point, you have a VRC tree in which the net patches are installed in separate VRCs. In general, customizations are developed based on a net patch. Sometimes customizations are not derived from a net patch. Or a customer wants to install parent standard product solutions that have components which overlap with the customization. Therefore, the option to derive the customization VRC from any possible maintenance stage of the parent standard product must be available. The P10U_a<n>_std update VRCs are introduced to achieve this. For every customization, an intermediate VRC layer is introduced in which standard solutions can be installed that do not belong to the underlying patch. You can use the session to populate the PMC registry for the P10U_a<n>_std update VRCs.

The customization VRCs P10C_a_cusA, P10C_a_cusB, and P10C_a_cusC represent various customizations that are derived from various patches. Suppose customization P10C_a_cusA is developed based on the net patch 1. During development of the customization, the P10U_a1_stdA VRC is still empty. After the customization is released and the customer installs the customization, the customer might want to install solutions of the standard parent product that also require an update of the customization. In this case, the customization vendor can install the solutions of the parent standard product in the P10U_a1_stdA VRC. Then port the solution to the P10C_a_cusA and provide a corresponding solution for the customization VRC. Installation of solutions in the P10U_a1_stdA VRC only affects the P10C_a_cusA customization and does not affect the other customizations in the environment.