60 likes | 211 Views
Example for j2ee software component’s versions from SAP. Lazar Borissov SAP Labs Bulgaria. Component Versions – basic information. Unique Key – does not change during lifetime Component name – ex. J2EE-CORE-SERVER Component vendor – initial version provider, example sap.com
E N D
Example for j2ee software component’s versions from SAP Lazar Borissov SAP Labs Bulgaria
Component Versions – basic information • Unique Key – does not change during lifetime • Component name – ex. J2EE-CORE-SERVER • Component vendor – initial version provider, example sap.com • Version information • Release – major version • Support package – major part of minor version • Patch number – minor part of minor version • Provider – this version producer, may be different from the vendor, example Some-Sap-partner.com • Background • SAP ships the component and regular/irregular updates to it. SAP is the component vendor and this never changes • Partner/Customer may do modifications to this component. He becomes provider for this modified version. He must hold the release but may change support package and patch version to whatever he decides. In component meta-data is added information for original SAP version • If SAP ships update the customer must adjust his modifications into SAP new version, new provider version is produced
SC A SP 2.0 SPP 2.1 SPP 2.2 SPP 2.3 SPP 2.4 SP 1.0 SPP 1.1 SPP 1.2 SPP 1.3 SPP 1.4 SPP 1.5 SP 3.0 SPP 3.1 SPP 3.2 SP 4.0 SPP 4.1 SP 5.0 Does new version contain everything what is in the system, the same release and provider Explicitly covered by SP5.0 i.e. defined in SP5.0 meta-info Implicitly covered by SP5.0 Not covered by SP5.0 i.e. contain corrections not included in SP5.0 The new SP to be applied
SP 1.0 SPP 1.1 SPP 1.2 SPP 1.3 SPP 1.4 SPP 1.5 Does new version contain everything what is in the system, other provider SC A SP 2.0 SPP 2.1 SPP 2.2 SPP 2.3 SPP 2.4 SP 3.0 SPP 3.1 SPP 3.2 Originates from SP 4.0 SPP 4.1 SP 5.0 SP 3.0, Some-Sap-partner.com Merged new modifications Originates from Direct/Indirect predecessor SP 8.2, Some-Sap-partner.com
SC A SC A SC A SC A SP 2.0 SP 2.0 SP 2.0 SP 2.0 SPP 2.1 SPP 2.1 SPP 2.1 SPP 2.1 SPP 2.2 SPP 2.2 SPP 2.2 SPP 2.2 SPP 2.3 SPP 2.3 SPP 2.3 SPP 2.3 SPP 2.4 SPP 2.4 SPP 2.4 SPP 2.4 SP 1.0 SP 1.0 SP 1.0 SP 1.0 SPP 1.1 SPP 1.1 SPP 1.1 SPP 1.1 SPP 1.2 SPP 1.2 SPP 1.2 SPP 1.2 SPP 1.3 SPP 1.3 SPP 1.3 SPP 1.3 SPP 1.4 SPP 1.4 SPP 1.4 SPP 1.4 SPP 1.5 SPP 1.5 SPP 1.5 SPP 1.5 SP 3.0 SP 3.0 SP 3.0 SP 3.0 SPP 3.1 SPP 3.1 SPP 3.1 SPP 3.1 SPP 3.2 SPP 3.2 SPP 3.2 SPP 3.2 SP 4.0 SP 4.0 SP 4.0 SP 4.0 SPP 4.1 SPP 4.1 SPP 4.1 SPP 4.1 SP 5.0 SP 5.0 SP 5.0 SP 5.0 Releases in the picture – not covered yet by the model • Main issue – component refactoring is allowed on release basis. Predecessor may be not A and not even one component or complete component Release 1.0 Release 1.5 Release 1.7 Release 2.0
SC A requires SC B SPP 3.8 SP 1.0 SPP 1.1 SPP 1.2 SPP 1.3 SPP 1.4 SPP 1.5 SP 2.0 SPP 2.1 SPP 2.2 SPP 2.3 SPP 2.4 SP 3.0 SPP 3.1 SPP 3.2 requires SP 4.0 SPP 4.1 SC C SPP 2.4 SP 5.0 Dependencies between software components • Here B and C require A to be on at least some version. The question is if A / SP5.0 can satisfy both? SC B / SPP 3.8 can be deployed, SC A / SP 5.0 satisfies requirement SC C / SPP 2.4 cannot be deployed, SC A / SP 5.0 does not satisfy requirement