We’re excited to share our new release versioning strategy, designed to offer you more control and clarity over your AYON deployments.
We believe that this is a solid long term plan, but welcome suggestions for improvements of course!
After a substantial deliberation, it became apparent that this is a good opportunity to differentiate between the server and the pipeline releases. What you will see with all AYON releases from now on are two separate version streams.
AYON server
and
AYON pipeline
This distinction is essential for clarity, because while it’s technically possible to use the Server without the Pipeline, the reverse is not true.
AYON Server Releases
Our AYON Server releases focus on a minimal installation of the server itself, including only the backend and web frontend. Each server release will be available as a tagged image on Docker.
The numbering for server releases is based on the BackendVersion+FrontendVersion. For example, an AYON Server release might be labeled as “AYON Server v1.0.0+230903”, which would contain ayon-backend-1.0.0 and ayon-frontend-230903.
Examples of AYON server versioning
This allows for strictly sticking to semantic versioning of the server backend which is the most crucial element of the whole platform. Given a version number MAJOR.MINOR.PATCH, we increment the:
- MAJOR version when we make incompatible API changes or bigger database schema changes that require existing data to be modified.
- MINOR version when we add functionality in a backward compatible manner, or simply extend the database schema.
- PATCH version when we make backward compatible bug fixes.
We will not be too precious and scared to update the major an minor versions if the changes require it, the consistency and trust within the versioning system is more important than trying to pack each major server release with tons of new features. If we break compatibility with API, we up the major version.
Frontend doesn’t affect the rest of the pipeline functionality, hence we can afford to use simple date based versioning for it.
AYON Pipeline Releases
In contrast, our AYON Pipeline will be released in so called release bundles, which provide a full pipeline configuration that’s ready for production use. We will also able to offer multiple flavours of each release, such as:
- Full suite
- 3D Animation
- 2D Animation
- VFX Studio
Each flavour contains a different subset of the same release bundle, but they can easily be combined. The numbering for pipeline releases is based purely on dates (YYYY.M.#). For example, an AYON Pipeline release might be labeled as “AYON Pipeline 2023.11”.
These are technically “pinned versions” of addons that are cross-compatible. We recommend that studios always start from the latest Pipeline release bundle.
Each AYON pipeline release will have minimum server version associated with it.
We believe this new versioning strategy will provide you with a more streamlined and efficient AYON experience. As always, our team is here to support you and answer any questions you may have.
Addons
All addons follow semantic versioning and are versioned independently from all other addons. Of course it can happen that an addon is dependent on another addon and it’s particular version. If that is the case this dependency can be defined and AYON bundles will be validated on the server to prevent any incompatible combinations. Details of the bundle validation system will follow a bit later. But long story shorts. Rez is involved on the server side ;).
Stable, LTS, Production… and other assurances
Marking release as production ready will not be happening at the point of release, but only once the release has been validated by multiple parties, not just our internal testing. It is entirely possible that we will release multiple official pipeline bundles in a given month if we need to, but only mark one of them as production a few weeks later.
That strategy should provide all studios with a clear choice between:
DEV - Bleeding edge of everything, updated often. Unsafe for production and and overall team sanity
RELEASED or LATEST - Most probably stable, but not yet extensively validated for production use. Should be safe for studios that have pipeline team able to react to potential issues.
PRODUCTION - Validated with multiple parties and deemed stable for production. The most conservative choice that will be usually a few months behind the latest developments.