Workfile versioning during publish

Ideas
1

Problem

We are having only one versioning schema at this moment. The version which is kepth in a file name or db document is either workfile synced or saved on next available. This will work usually in most cases and for most of produtions. There are still productions which are working on client review version sync - it means they want to keep as few versions as possible and each version refers to reviewed version with some given feedback from client or internal loop.

Now you might think this is still doable with the OpenPype, the only thing is to not version up workfile, but that would work only in case users would iterate user-versions for them selves with some sort of local rendering or render farm submitters - and not by using openpype publisher as a way of submitting (because they want to use the power of validators).

Well you get the idea what is the problem. Another thing is that we are requiring workfile instance to be part of publishing context as active as it is usually required by integrate plugin as it needs to use the source path in version data.

Solution idea

My idea is to use versioning and snapshots. Snapshots are only generated short hash string added as suffix to workfile after it published. As for example after we had published from nuke just gizmo family instance, we would save new snapshot of workfile as workfilename_v002_oxw2o.nk and this way we would keep the version of file untouched. The version would increase on workfile only if review toggle would be activated on render family and its derivates (.local, .farm). So you can imagine this would need some sort of rules to be used on some Global Scene Version Up plugin activated only in case of host, taskType, family would match.

Known caveat to be solve would be what if we want to keep version synced some families to workfile and those families are not part of client review cycle - like for example Nuke’s prerender families. Yes those are challenges to be solved. Perhaps we could allow version to have dashed or dotted separated minor versions like workfilename_v001-02_oze6ze.nk where template would be something like {name}_v{version}-{minor}_{snapshot}.{ext}

Has been discussed here Settings for Nuke IncrementScriptVersion by kalisp · Pull Request #2039 · ynput/OpenPype · GitHub

2

workfilename_v002_oxw2o.nk vs workfilename_v002_s011.nk

I really like the “snapshot” idea. What is the advantage of the hash string compared to simple counter? Productions with client versioning often need to keep an internal approval circle. Talking about version 2 step 11 seems much easier than v2 oxw2o.

I am fan of “composite versioning” where every client version is in hundreds. So v0107 is client version 1, step 7. Versions are raised as usual, the only difference is that artist manually changes version to the next hundred after receiving client review.
ie v0107 shared with client; client asked for changes; next version is v0200, made from v0107 by artist
Advantage is that all the versioning works as is, and client versions are clearly seen for everyone. Disadvantage is that for v%04d you have “only” 99 client versions and each client version can have only 100 steps.
Clients are often fine with keeping the whole version, so flooring whole version to hundreds is often not necessary.

3

I really like the approach of client version to be at handsets. Snapshots as hash string was just an idea - I am counting algorithm getting last workflow sorted also by timestamp - but yes, it would not be as human readable.

To expand on the idea: how about to allow version to be in float? So client version would be whole number and user cycle would be decimal. workfile_v001.001_commit_message.nk - the commit message is already part of workfile. {name}_v{version:.3f}<_{comment}>.{ext}. In nuke we could add submission toggle to client which would be active only if review would be activated.