Overview of Component Versioning

Isight has a built-in version control capability that allows different versions of the same component to be used by Isight models and maintained within the Library.

Component version numbers as coded in the metamodel XML can be anything the developer wants. They have no correlation to Isight infrastructure versions. For example, components released to work with Isight 2017 do not have to start with “5”; you are free to alter the version number in the metamodel XML at any time. However, it is good practice to follow the convention of the SIMULIA components, which is described in the remainder of this section.

The version numbering convention used by SIMULIA components is a three-part number notation (“a.b.c”) in which the last part of the version number is generated at build time and contains a time/date stamp. This arrangement allows every individual build of a component to be distinguished from previous builds without requiring any particular action on the developer’s part. This practice is good for field problem determination and debugging. Even if the component source does not change from one build to another, the compiled classes and other content in the component JAR can be different because of build system changes and changes in other included supporting files.

If you are considering altering the version number, there are some system implications of which you need to be aware.

When a model is saved, the model XML contains the version of the component that existed at the time of the save. By default, the model XML will also contain a specification about what versions of the component are allowed to load this model in the future. By default, this version is the component's major version number followed by wildcards for the second and third levels; for example, LoadVersion=“5.*.*”. In this example any version of the component that starts with “5.” will be allowed to load this model. No “3.x” or “4.x” versions will be allowed to load the model. If the library does not contain a suitable version of the component, the model will fail to load.

If you cannot make a component backward compatible (e.g., able to read properties from models that used prior versions of the component), you can release the component with a new major version number. This action will prevent the loading of existing models with the new nonbackward compatible component version.

If you always maintain backward compatibility of your component, the major version number will never change.