Currently Zeffiro Interface contains at its core a god object or struct zef, which is responsible for storing most if not all of the information needed by the program. For a stable release, the names and types of the fields of this struct like zef.nodes and zef.tetra need to be documented and attached to the semantic version numbers (major.minor.patch) of Zeffiro Interface, to make users and developers aware of whether something has changed in a way that requires them to update their code or Zeffiro projects.
In practice this means that if a new field is added to zef, such that backwards compatibility is not broken, the minor version is incremented. If a field is added, modified or updated to be used with another field, such that backwards-compatibility is broken, then the major version is incremented. If a bug with existing fields is fixed, the patch version is incremented.
As a suggestion for a possible first implementation, a function zef_core_struct or similar could be written, that returns a default version of the struct with all possible fields initialized to some valid value. The validness could be enforced by using name–value arguments with default values via Matlab function argument validation. The fields of zef could then be documented in the documentation comment of this function.
This approach would allow a user or caller to modify individual fields during initialization if required, but leave them as-is, if there is no need to modify the default values.
Currently Zeffiro Interface contains at its core a god object or struct
zef, which is responsible for storing most if not all of the information needed by the program. For a stable release, the names and types of the fields of this struct likezef.nodesandzef.tetraneed to be documented and attached to the semantic version numbers (major.minor.patch) of Zeffiro Interface, to make users and developers aware of whether something has changed in a way that requires them to update their code or Zeffiro projects.In practice this means that if a new field is added to
zef, such that backwards compatibility is not broken, theminorversion is incremented. If a field is added, modified or updated to be used with another field, such that backwards-compatibility is broken, then themajorversion is incremented. If a bug with existing fields is fixed, thepatchversion is incremented.As a suggestion for a possible first implementation, a function
zef_core_structor similar could be written, that returns a default version of the struct with all possible fields initialized to some valid value. The validness could be enforced by using name–value arguments with default values via Matlab function argument validation. The fields ofzefcould then be documented in the documentation comment of this function.This approach would allow a user or caller to modify individual fields during initialization if required, but leave them as-is, if there is no need to modify the default values.