The Media Versioning format is:
{File Identifier/Name}.{MAJOR version}.{FIX version}.{file extension}
Given a media file (audio, video), the version number (MAJOR.FIX) is appended to the filename with a dot, and increments the:
For example, the first version of a program for delivery to streaming services would be named:
TDYE190045-FallUpdate.1.0.mp4
A subsequent version for delivery after a typo in a lower third has been identified and fixed would be:
TDYE190045-FallUpdate.1.1.mp4
Like their programmer counterparts, media content creators should use a standardized system to encode useful information about the file version in their filenames. Media Versioning is just such a system.
Media Versioning is a simple set of rules and requirements that dictate how version numbers are assigned and incremented to audio and video files in a production environment.
Under this scheme, version numbers and the way they change, convey meaning about the underlying media file and what has been modified from one version to the next.
A normal version number MUST take the form X.Y where X, and Y are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, and Y is the fix version. Each element MUST increase numerically. For instance: 1.9 -> 1.10 -> 1.11
Once a versioned file had been rendered and delivered to a customer/end-user, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.
Major version zero (0.y) is for rendered versions not meant for final release like editorial and quality control review versions.
Version 1.0 defines the base deliverable for distribution (e.g. broadcast, streaming). The way in which the version number is incremented after this delivery is dependent on any fixes or other revisions.
Fix version Y (x.Y | x > 0) MUST be incremented if only minor changes and fixes are introduced. A fix is defined as an internal change that fixes incorrect audio or video presentation.
Major version X (X.y | X > 0) MUST be incremented if any structural or significant content changes are made. It MAY also include fix level changes. The fix version MUST be reset to 0 when major version is incremented.
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the fix version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0-alpha, 1.0-alpha.1, 1.0-0.3, 1.0-x.7.z.
Rendering metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the fix or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0-alpha+001, 1.0+20130313144700, 1.0-beta+exp.sha.5114f85.
Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into major, fix and pre-release identifiers in that order (Rendering metadata does not figure into precedence). Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, and fix versions are always compared numerically. Example: 1.0 < 2.0 < 2.1 < 2.1. When major, and fix are equal, a pre-release version has lower precedence than a normal version. Example: 1.0-alpha < 1.0. Precedence for two pre-release versions with the same major, and fix version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0-alpha < 1.0-alpha.1 < 1.0-alpha.beta < 1.0-beta < 1.0-beta.2 < 1.0-beta.11 < 1.0-rc.1 < 1.0.
*Note: The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
This is not a new or revolutionary idea. In the programming world there are well established (and much more detailed) systems for handling application and code versioning. One such system is Symantic Versioning, upon which this system is based, It is common for creative professionals, without any programming background, to not understand the existence or importance of formal specifications for versioning. Without compliance to some sort of formal specification, versioning attempts are usually too inconsistent to add value to a production and media management process. By following a versioning system, it becomes easy to communicate your intentions to your team and the end users of your media files.
If all of this sounds desirable, all you need to do to start using Media Versioning is to declare that you are doing so, and then follow the rules. You can share a link to this website so others know the rules and can benefit from them.
The simplest thing to do is start your initial development renders and review version at 0.1 and then increment the fix version for each subsequent render/review version
If the media is being used out in the wild, it should probably already be 1.0.
No, but use good judgment. A 255 character version string is probably overkill, for example.
No, “v1.2” is not a proper semantic version, although prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. It is not needed or used in Media Versioning.
The Media Versioning specification is authored by Robert Travis Pierce. After fruitlessly searching for any kind of standard version naming practices in media production environments, he decided to create one, borrowing heavily from the programming world’s Semantic Versioning—thank you Tom Preston-Werner!
Robert uses these principles daily in his work in production at Three Angels Broadcasting Network.
If you’d like to leave feedback, please open an issue on GitHub.