Questions about ACES transformIds, versioning, and release strategy

[c-clark]

ACES transformIds and versioning:

Context
In the last months new CSC transforms have been published on https://github.com/aces-aswf/ , for example, Leica L-Log (Nov 2025) and Apple Log 2 (Feb 2026).
Customers and partners are approaching Pomfort with the question if we can support these transforms.

Situation
The ACES main git repo at https://github.com/aces-aswf/aces has a transforms.json file, that is said to be "the truth".
The submodule "aces-input-and-colorspace" has commits with the new transforms, but these are mixed with changes in transformIds of existing CSC transforms:

• a2bc3b (Nov 2026): Update transform IDs for CSCs that were not updated to the 'a2' token [transformId change]
• 0d162e (Nov 2026): Add CSCs for Leica L-Log [new transform]
• d2e909 (Feb 2026): Reorganize Sony transforms [rename of CTL files]
• 2331f7 (Feb 2026): Add CSCs for Apple Log 2 [BOTH new transform AND transformId change of existing Apple Log transform]

All these commits are on the main branch of the "aces-input-and-colorspace" repo.
None of these commits are referenced by the mainbranch of the "aces" repo, and not included in the transforms.json

Questions

1. How shall we provide customers with latest additions to the "aces-input-and-colorspace" repo?

Breaking changes like renamed transformIds are mixed with new transforms in the same main branch, sometimes in the same commit (e.g. 2331f7). Currently the only way is manually judging which of the added transforms are "ready" and manually porting the CTLs and transformIds to our implementation.
As the AMF implementation guide states ...

When creating or parsing an AMF, software should validate transformId's against this registry. If a transformId is not found in the registry, it should be treated as a custom or unknown transform....

which would require such "new" (added in the last 4 months) transforms to be only recognized as "custom" transforms - without any strategy for interoperability.

2. How is the general release strategy?

Breaking changes like renamed transformIds require dedicated release events. With the introduction of the transforms.json even adding transforms now requires a release.
The AMF implementation guide doesn't mention how the previousEquivalentTransformIds tag in transform.json should be treated – presumably to mitigate the issues created with renamed transformIds. Do we need to implement that as a vendor reading AMF? Does this mean users can load AMFs with transforms mixed from different ACES versions if they appear in the previousEquivalentTransformIds? Can we trust that entries in previousEquivalentTransformIds are mathematically equal transforms?

[scottdyer]

I had started trying to codify some of this in the aces README.

I think adding automated staged updates to transforms.json as part of the notify-parent automation will help with this. The idea (which I've tested in a limited form but at the time had waited to leverage the transformID python libraries) is to have a running staging of changes on a PR for transforms.json. I also want a running human readable changelog, which we use to help guide our review and in the process make edits to as part of a pre-release review process.

We could also commit changes to transform.json directly on main between releases, but that could be confusing because we'd need to a placeholder tag for that json section, which would be codified with the exact verstion tag string when the release is made. As currently stated, things are not "official" until a tag is added, which triggers the release process which will:

• commit the new version tag as a new entry in transforms.json
• commit a finalized version of the CHANGELOG, as a human readable rollup of "New", "Bugs", etc.
• create a ZIP package with the included transforms for laypeople to download

The big issue is that we hadn't implemented this before merging in the various IDT changes and so have stuff unsynced due to many pieces changing. I need to get everything aligned for a new release to clean up all the unsynced items. And as a group we can figure out how we want the automated handling to operate.