Open RV Long Term Support
Name | Note | Date |
|---|---|---|
Alain Compagnat, Guillaume Brossard | Initial Draft | May 5, 2025 |
Context
Open RV code has been published to ASWF, a little bit less than 2 years ago now. Community and studios are starting to consume Open RV and contribute to it. A new concern arise - What is the long term support model for Open RV. It takes time for studio to update and adopt a given version of any software and the want to make they will be able to get support or self serve their support over time.
We also want to determine when we do update to align with VFX Ref Platform recommendations in Open RV as well as in relation to other ASWF components such as Open EXR, OCIO, OTIO, etc.
Proposed support plan for Open RV
Release Versioning
Aligning with the VFX Reference Platform and support the current release and the two preceding majors.
High Level Guidelines
Main branch is dedicated to next release
Each releases have a dedicated release-branch.
All features are going in main
Small features can be nominated to latest release-branch and if the minor version is bump.
All fixes are fixed in the current release
Fixes can be nominated to be also back ported to previous releases up to 3 releases behind the latest.
Back ports to previous releases can not break compatibilities and APIs
Each release-branch support only one VFX Ref Platform
Each release-branch has CI capabilities
Version Numbering
Major release: Use for VFX Reference Platform change or any other library dependency major updates. E.g. FFmpeg 6 to 7. Or new core feature will be proposed
Minor release: Use for new non core feature or any other library dependency minor updates. E.g. AJA 15.1 to AJA 15.3
Patch release: Use for defect fixes.
VFX Ref Platform alignment
Each release-branch will support only one VFX Reference Platform standard. E.g. 2.0.0 support CY2023
Main branch will slowly integrate the next VFX Reference Platform standard, no longer need a build switch.
Example of alignment between Open RV versions and VFX Reference Platform
Open RV Release | VFX Ref Platform | Strategy | Comments |
|---|---|---|---|
1.x (oldest) | CY22 | Part of the original source publish |
|
2.x (previous) | CY23 | Add support for CY23 |
|
3.x (current) | CY24 | Add support for CY24 |
|
main | CY24 and CY25 | Add support for CY25 with a build switch | Much easier to keep up to date but it can make the code look fragmented with all the if CY24 else CY25. Does not scale well to support more than 2 VFX Ref Platform CY in parallel |
Support
We will document in the repo, which branch is currently supported and what is the nomination process for release-branch.
We will never delete the release-branches, it will be there for any one interested to back port fixes in a no longer supported branch. More then 2 releases behind the latest.
CI
CI is supported on main and 2 release-branches for multiple OSes.
Challenges of the proposed approach
Challenge | Description |
|---|---|
CI Upkeep | In addition to maintaining 3 branches in parallel, the CI to build the different branches also need to be maintain. |
Important back-port effort | With this approach, most of commits going in main will end up at least in the previous minor branch. This can be mitigated by being more stringent about what is automatically back-ported and let the community contribute to the effort. |
Open Items
We'll need to provide a clear plan about the following:
Release Version planning when do major, minor, patch release goes out?
How do we support major or minor releases?
Which releases will bring the VFX Ref Platform update? How? (build switches, branches, ??)
How long will a major releases be supported?
What is the process to nominate fixes in LTS branch?
Do we provide CI for all the releases?
Resources
Resource | Description |
|---|---|
Providers of software libraries focused on VFX and animation content creation should aim to support their releases for the current calendar year and the three preceding years with compatible updates. Studios and end users should have no expectation of support for older libraries. The VFX Reference Platform strongly recommends open source project maintainers provide a level of support described by the FLOSS Best Practices Criteria, which is already a requirement for all Academy Software Foundation projects. | |
The Blender LTS program is aimed at ensuring that long-lasting projects can be executed using a stable Blender version, which will provide critical fixes throughout a 2-year time span. The LTS version will not have any new features, API changes or improvements. Any critical fix that is applied to the latest stable version, will be regularly ported over to active Blender LTS releases. |