Hello, here is my thought on this, if this could help you :
Developing a “product” is complicated, this step includes keeping track of the version released, especially if in our case, the final product is made of other ones. Right here we have three products ! ACES, OCIO and the ocio config in itself.
ACES
ACES alone, is a “collections” of requirements, standards, transformations, etc. Each update to one of these parts produces a new version like the well-known versions 1.3, 1.2, … that is published and tell “to have ACES be considered as X version, you have to update, modify this”.
As you may have noticed, the few years have only seen an increment in the “minor” number of the version. This is because, since ACES 1.0, the change didn’t affect enough the “product”(ACES). I can’t really tell you what does make ACES, “ACES” (it’s being discussed right now) but what I know is that ACES 1.0 defined mostly the “look” of the RRT and, this “look” has only received very minor updates/fix. (anyone corrects me here)
OpenColorIO
But ACES alone is just “a bunch of rules”, that you have to translate to your digital software. This is where OCIO came into play. See it as a language that your software can convert to its own language. Or if I may, see it like a “plugin” extending your software, so all of them implementing OCIO can understand the same language.
OCIO being an individual “product” have different versions. You might have heard about OCIO 2.0 (which was just called OCIO before) and all its subsequent releases like OCIO 2.1, …
Each of these versions includes new features, changes how you speak the “language”, fix bugs, … the usual stuff. OCIO 2.0 included a bunch of new big features (that’s why it got incremented from 1.0 to 2.0), one of them being builtins transforms. These transforms are mostly the transforms defined in the ACES standard for color transformations.
Previously (and still now), to create a color transformation (ex: from colorspace A to colorspace B), you had to specify “the mathematical formula” in the .ocio config to perform the operation you want. This transformations could be supplied as external files like LUTs, this explains why the ACES most spread configs have some luts files alongside them.
But as I mentioned in the previous paragraph, OCIO 2.0 removed the need for these LUTs because they are now part of OCIO as builtins transforms. This means that the ACES OCIO config can now be expressed as simple single .ocio file.
the .ocio config
And our last product is the “config” itself which is here for ACES but could be for anything else. You still want to keep track of it, for example, a transform had an incorrect name and you fix it. This is specific to this config only so you will need versioning for the config itself.
This should explains the 0.2.0 you see, that is for this specific “self-contained” config, which then use OCIO 2.0 (because of the builtins transforms). And those builtins transforms + the config refers to the standards defined in the ACES specification for ACES version 1.3 (correct me here).
Which well a lot of versions to digest for the end non-technical user. But it is still a pain for developers when you have to keep track of “which version of each product needs which version of X other product and what is the current version we are using.”
I hope this made things clearer and is also not a too simplified version. Anyway if someone sees something incorrect let me know so I can update it.
I used ACEScg values for the spheres and cranked up the exposure up to 7 stops.