Document ACES and config versions in the config
doug-walker opened this issue · 1 comments
There are several different versions that are involved in a given config instance:
- The version of the OpenColorIO config file format (currently 2.1, soon to be 2.2)
- The version of the ACES system (currently 1.3, soon to be 2.0)
- The version of a given instance of the config (e.g., changing as color spaces are added or removed from the spreadsheet)
The OCIO config file format is documented as the "ocio_profile_version" on the first line of the config. The other two should also be documented in the config, ideally in a way that is both machine readable and human readable.
In addition, we may want some of these versions to show up in the name of the config file itself.
The working group has discussed these topics several times but I don't think we ever came to a conclusion on how this will work. Creating an issue here since the Python code probably needs to be updated to reflect whatever the decision is.
Of course, there is a fourth version which is the version of the Python generating code, but my guess is that this will not affect the usability of the config enough that it will be a significant concern. The config description string already seems to contain a creation date and corresponding release version and git commit hash for the Python generating code itself and my view is that that is sufficient. But I think we do need some more formal way of recording the other three versions listed above.
I propose that the "name" attribute of the config object be used to hold a human & machine readable string that includes these three versions. (In Python this would use the Config class setName method.)
For example the name string could be something like: "Studio Config for ACES 1.3 [OCIO v2.1] [color spaces v0.2.0]"
Should the file name of the config itself include these too? For example change "config-aces-cg.ocio" to something like:
"cg-config_aces-1.3_ocio-2.1_colorspaces-0.2.0.ocio"
Of course, the config is a text file and may be edited, so there is no guarantee that a given config name string or file name will be as reliable as a hash of the file. Nevertheless, a versioned name string of some sort is more human readable and could be quite helpful as a first piece of information to ask for when investigating user problems.
Closing this as done since Thomas implemented it in PR #50.