The simplest approach to managing change is to introduce the notion of a version. This approach is already well known and used for documents, software, parts, and CAD drawings. Basically, a version number is assigned which is incremented for each revision of the information that is versioned. Version numbers can be structured, for example, many PLM systems divide the version identifier into a revision and an iteration such as B.3 (Revision B, 3rd iteration).
This way of versioning becomes a challenge when several objects are related, each of which are versioned. If object A refers to and depends on object B, should the version of A be changed if we only update object B?
In software development, where thousands of files make up an application, the approach to versioning has evolved from a simple local strategy with a version identifier per file, to advanced distributed and graph-based approaches such as Git.
A product model, consisting of a large number of configuration parameters and rules, is fundamentally no different from managing the source code for a software application:
- All changes must be tracked (who has changed what and why)
- Multiple people may modify the model concurrently, potentially modifying overlapping aspects of a model
- Given a version identifier, it must be possible to precisely establish the corresponding set of parameters and rules