Every class in the SansGUI environment has a version number with the purposes of: 1) identifying the class for checking simulator compatibility, 2) managing class schema changes made by the simulation developer and 3) updating simulation users' data files to synchronize them with newer or older class schemas.
A class version consists of four integers for: the major release, the minor release, the patch level, and the build increment numbers in the following format:
<Major>.<Minor>.<Patch>.<Build>
Major Release: for significant features and enhancements in the simulator. The major release number starts from 1.
Minor Release: for minor enhancements in the simulator. The minor release number starts from 0.
Patch Level: for maintenance releases including bug fixes. The patch level starts from -2 (alpha testing), -1 (beta testing), and then 0 (official release), followed by positive integer numbers.
Build Increment: to record in-house build number, starting from 0.
When a class is first created, the associated version number is always 1.0.alpha.0, meaning that it is targeted for version 1.0 release but still under alpha testing cycle with build number 0. Use the in-house build increment to identify the testing versions until reaching the beta testing time.
The version number is automatically maintained by SansGUI and the version advancement operations are invoked by the simulation developer. However, the simulation developer cannot edit the version numbers manually.
A class version is advanced when the simulation developer generates a new Object Library from a Schema Definition. Except for the simulation control classes, whose versions will be advanced whenever a new Object Library is generated, a class version will be advanced only when the class schema changes. The version number in the simulation control classes represents the version number of the simulator. When there are more than one simulation control class in a simulator, the versions of these classes are always advanced and synchronized. Operations for advancing the versions of the classes in a Schema Definition can be requested via the following:
Next Build: when in-house build is requested, the build number will be advanced by 1.
Test Release: when switching from an official release to the alpha version of the next major or minor release or from an alpha release to beta. If the beta level is reached, only in-house next build can be used for test releases.
Official Release: when an official release is requested, the build increment will be cleared to 0. The version advancement requests may be for a new major version, a new minor version, or a patch version. If the original version is a test release, both the patch level and the build increment will be cleared to 0.
When the simulation developer generates a new Object Library from a Schema Definition, the classes with the old version prior to the generation process are backed up in a file with the file name indicating the new version number. The back up file should be treated as the state of the Schema Definition prior to the new version. The simulation developer can use the backup file for branching versions, but should not use it to defeat the version control purposes. Suppose a simulation developer generates a major release 2.0.0.0 from an original version 1.2.3.5. The backup file can be used to generate a patch version 1.2.4.0 and then on to a minor release 1.3.0.0. It is not a good idea to create version 2.0.0.0 again from version 1.2.4.0 or 1.3.0.0 because two versions of 2.0.0.0 Object Libraries with different contents may then coexist.
The class schemas containing version numbers are stored in the Schema Definition and compiled into an Object Library for distribution with a new simulator. When the new Object Library is chosen by the user for updating an older Project Model, the class definitions in the Project Model will be updated and all the user's data will be converted to fit the new definitions. If default values are given to newly added attributes, they will be copied to all newly created data fields. The simulation developer can freely add, delete, or change class attributes without worrying about obsoleting users' Object Libraries and Project Models. This process can be applied to simulators with either later or earlier versions, yielding forward and backward compatibility.
|
|
SansGUI Modeling and Simulation Environment Version 1.2
Copyright © 2000-2003 ProtoDesign, Inc. All rights reserved.