I’m curious how people have gone about this with OP in the past. For our work we typically have internal version numbers (good 'ol regular publishes) then we deliver client versions which is a separate version number, so we deliver our v006 as a client version 1, then our v009 becomes client version 2. Any experience getting that set up with OP?
One idea I had was to have a delivery subset to track these versions, so when a version get’s delivered we create a delivery version along with it, to track that delivery version
1 Like
Cant comment on how to do this, but have always been curious about why this workflow is in place.
Is this a requirement from the client or a matter of internal tracking of versions?
We’ve never needed to separate internal and external versions.
This is a requirement from the clients.
We have even had times when exr deliveries were versioned separately from mov deliveries 
The way I do it in Fusion is I create the workingfile with the subversion set to 001
When I then save new version from Fusion itself it versions up the subversion
but when I publish the workfile + versioning up from OP the v001 gets versioned up
It’s not perfect and not automatic but kind of work.
But to have a dedicated {delivery_version} could be nice
We would require the same. Client versions use totally different versioning, naming, shot codes, even sometimes with or without slates or handles. And then we need a link to tell which internal version matches so notes on that version can be put in the system and track to the correct internal versa ion.
This includes a version zero sometimes as well.
1 Like
Think this might be a good route to take. You’d essentially “publish” a delivery which can keep the links of all the versions/representations involved. On this note think it might be the same as package; Implement Package family · Issue #2724 · ynput/OpenPype · GitHub
Copy pasting my comment from Discord
A possible solution would be to expose a new field on the templated system like {delivery_version} that we can use on the delivery template and it versions up automatically based on the number of delivers
I really like the idea of the delivery version separable from studio versions.
Maybe new tags can be (ab)used for client versions?
Clients have often very specific requirements, like:
- submitting “version zero” (conform check) in different format comapred to the “normal” version stream
- having versions started from specific number, like 0, 7000 (for encoding lucky vendor number 7 to the version…)
Being able to start working early, with flexibility to allow for client requests as they come is huge timesaver.
Unfortunatelly, clients (almost) always require the version number to be burned in the review files and in the slate. We would have to have some mechanism to produce “delivery reviews”, with “delivery slate” on demand, or republish every version for client delivery.
1 Like
Great point on the delivery reviews + slate on demand, we were recently discussing exactly how/if we are going to support these features in OP as that’s how our current pipeline works and our editorial artists are used to… For now I’m trying to shift the mentality a bit and get used to the fact that we will be creating all the review deliveries on each publish and not on demand but I’m unsure if that’s going to have a much bigger storage footprint. Worst case I was going to write a CLI that runs the extract review plugin as part of the delivery action
I do not see creating all the review deliveries on each publish as a big issue. The disk space is cheap, but time is not.
Trouble is, that some info is not known when artist publishes the version. For example, does the supervisor want to send this version as a wip or proposed final? And with what note? Surprisingly often this info travels via slate and/or burnin, instead of metadata / database.
1 Like
I second having this as an option, like a new publish familiy like “deliveryPackage”. I don’t mind having the actual stuff done for each publish, but the ability to deliver with standalone or nukestudio or resolve would be really hando for clients that are not accustomed to jumps in versions. The ability to retrieve version number from the rendered source is already there, and one could include it as an optional on the slate.