We have had several discussions lately about version numbers inside SMTK files. This page exists to summarize, discuss the use cases involved, and document our decisions.
Uses of Versioning
We have identified 3 different ways versioning is being or will be used in SMTK:
- to track the provenance of user-generated data. For instance, we wish to determine when opening an attribute resource whether the information in it applies to the current model file it lists or some predecessor (i.e., has the model been changed without updating the attribute – perhaps because the attribute was not loaded when the model was changed?).
- to tag the schema of an attribute so that applications and/or operations know how to process it. Some applications may wish to support old attribute schema for a time. A particular use case is when multiple versions of a simulation code should be supported; features in the simulation code may change from version to version and require structural changes to the attribute system that prohibit a single schema for all versions. Schema versioning may be more or less granular:
- project-level (coarse-grained) versioning is possible once we implement projects.
- individual attribute, definition, item, and item-definition version numbers are available for fine-grained schema versioning.
- to identify the file format used to store resources. We need to be clear about which version numbers are used for file format versioning so that developers do not attempt to use them for any of the above.