(SM-2302) SM Version Update Tool

We had several issues with the backward compatibility in SM. The sole purpose of this functionality is to get rid of this problem.

Created a REPORT that will make all changes necessary, to make sure that the current updated version of SM is compatible with the old SM.

Scenario:
Adding a new required parameter to some existing storage.

Consequences:
All existing storages on the given system before the update won't have this parameter defined. As the required param is probably crucial for run-time decisions for given storage, the mentioned update will probably dysfunctional all old storages created on that system.

Solution:
*/DVD/SM_IF_VERSION_UPDATE* represents an interface for all fixing that must be done in order for it to SM works correctly with an updated SM version.
!Class diagram-SM version update.png|thumbnail!
Each class implementing an interface represents a fix for the delta between version V and version V-1(class /DVD/SM_VERSION_UPDATE_1807 will represent a fix between SM version 1806 and 1807, assuming there were such versions created). Version V does not necessarily have to be an official release version. It is a version for which the /DVD/SM_VERSION_UPDATE* class was created.

We will have multiple update classes and a new one will be generated when necessary. As each class represents only a fix for its delta, we always need to keep all previous classes.

Our report will get the list of all /DVD/SM_VERSION_UPDATE classes and execute them in the correct order, starting with the oldest. Each class will check if changes are necessary (could be already performed) and execute them accordingly. Changes could represent a fully automated process like filling in some necessary parameters for storage. It could also represent the interaction with the user, where the popup will inform him about what is requested and ask for user input.

Step-by-step guide

Handling as Developer using REPORT: /DVD/SM_VERSION_SETUP (at development time - when preparing for release)

This is to register a new VERSION CLASS, which will be responsible for version updates into the corresponding new version.

Both parameters are mandatory and the user has to fill in RU Version and Description for the new SM version.

After successful registration of the new class, the report will present a newly generated VERSION CLASS in the last row of the REPORT.

For example, as you can see in the image above, there is a new VERSION CLASS registered with the name: /DVD/SM_VERSION_UPDATE_00005.

2. Implement newly registered version update class: /DVD/SM_VERSION_UPDATE_00005 (at development time - when preparing for release)

The newly registered class has to implement also the interface: /DVD/SM_VERSION_UPDATE, which will force to implement the interface's method: adjust

3. Call REPORT: /DVD/SM_VERSION_EXECUTE to perform SM version Update (at installation time - when installing new SM version)

Users can choose the mode when to execute from the given version into the last version OR from the given version up to the given version

By default, the version updated call of all ordered classes from the version as given in the field Version From till the last version registered in the tool. The classes are executed one by one until the last class is triggered.

If it is required to execute from a given version to another given version, you have to check the checkbox Execute From AND To Version and then both parameters are required.

In this scenario, only classes from the given range will be executed.

If all went well (all classes exist, all classes have implemented the required interface, ... the method adjust is called on each of those classes).

The result of the run may look like this:

3.1 Scenarios when SM Version Tool detects the problem with implementing classes

3.1.1 Class is registered but does not exist

When the tool tries to execute the update method adjust of implementing class, it does prerequisites checks.

If any of the versions implementing class does not exist, it is reported and the tool won't execute any of them.

3.1.2 Class is registered but has not implemented interface