Something I’d like to implement in the near future is semantic versioning (semver) for work/publish scenes and products.
We use it daily as developers, and its a damn good tool to know the state of the repo at a glance.
Quick explanation for those who discover this concept:
Semantic versioning (1.10.2) gives meaning to your updates by incrementing three numbers (major.minor.patch) instead of a single number (v012).
With the classic linear versioning (v025 > v026) you need to read comments to know what really changed, you can’t easily branch off or come back to an earlier version without breaking the versioning history :
- Hey which one do I take ?
- So v075 comes from v012, but we went back to v036 which was better and saved it to v076.
- …
Sounds familiar ?
Now let’s imagine some scenario:
Anim:
you get from sq0100_sh0010-anim-v1.0.25 to ...v1.0.26, then you know only anim curves have changed. sq0100_sh0010-anim-v1.1.0 would mean the casting changed. sq0100_sh0010-anim-v2.0.0 could mean Editing got updated.
Modeling:
A rigger sees a modeling update on the minor version, he knows the topology or hierarchy changed and can react accordingly.
Shading: patch update → textures/lookdev updated minor update → network updated major update → added a shading variant
Layout: patch → moved assets minor → add/remove assets major → updated editing / camera
It would also be very useful for TDs to make tools that react to a version bump.
We would need to define what action triggers which update for each task.
I don’t think it would disrupt artists too much as you get your classic linear versions with the patch token.
I introduced this idea to some supervisors and artists. After a first automatic rejection, they saw the benefits of this approach and are now quite hyped.
The 3 words are arbitrary can be changed to help artists understand their meaning.
major.minor.patch
major.update.increment
etc…
Sounds like a good idea, but there is a steep learning curve for artists and a lot of ground work on terminology.
Mapping major, minor and patch onto creative work, I think will be very difficult to control and account for all cases.
I like the idea of giving more meaning to the versioning - I’m a bit worried though whether it’s worthwhile from an artist POV. Suddenly an “save + increment scene” becomes an extra decision making for them whether they are making a large change, an update or just a minor tweak. I’ve seen so many times that e.g. ‘many small iterations’ still make up for massive changes overall - then what is the cutoff point to be the next version. Then stepping at some point one major version down would still hold a lot of that “major change” anyway.
So, I’m mostly worried about how accurate artists might even end up correctly applying the meaning to the versioning, in any way. Plus the fact that it’s just much easier to refer to a v25 than a v2.11.15 file both internally but also in conversations towards clients.
I understand the reasoning - I just wonder whether, artist facing, this isn’t just much better resolved by having clear comments being produced with versions and being able to easily visualize such comments.
I think it’s much more important to understand what and why something has changed in a version than having just version numbers where you’d still need to end up identifying exactly what had occurred as “big change” or “small patch”.
I gotta say that I really struggle imagining a production where this would fly with artists. Semantic version works in software because It follows a fairly simply concept, but in art, you’re in for a massive range of changes.
Just the fact that you need to explain patch, minor and major for each task type as in your example, pretty much disqualifies the system from being really useful.
That being said, I love it from technocratic perspective
I agree there would be friction from an artist’s perspective for work files.
Those aside, it would make a lot of sense for publishes and products as they are consumed by other departments and “automatically” versioned.
That would make updates more meaningful and allow us toolmakers to provide tailored messages to the user when consuming new versions.
The difficult part is to compare any aspect that would trigger a version bump against the previous versions. Some validators could be tagged for that purpose.
This might be a hell to maintain in the long run…
Well, thinking about it, the real problem I’m trying to solve is to know what got updated (hierarchy, topology, set-dress, casting, etc…) semver might not be the answer.
Maybe some metadata alongside the files ? Comparing your current reference’s data against the new version would provide this information.
Maybe some metadata alongside the files ? Comparing your current reference’s data against the new version would provide this information.
I agree that knowing what has been done from v01 to v05 is tricky without digging through the comments. Maybe there should be a “release” notes that can show all comments between the versions you are updating?
This might make it easier to find some things related to it - plus the “Avalon Core” topic, where I originally implemented collecting input links for publishes also shows some ‘back in the day’ UI designs.
Aside of just seeing the comments I also really like seeing “all the dates” of the previous versions as well - so I can quickly see how often it was updated or when the updates were on older versions. Gives you a much better sense of what was going on with that product.
We’re fully on board with adding more relevant information about the publishes for the artist, but it will most likely be implemented as embedded web view showing activity section (which includes comments and any changes).
That is being developed for the web task dashboard atm.
